On Mar 20, 2012, at 1:03 PM, Kyle Sluder wrote: > Tried it. I don't believe it's possible. The whole point of scroll views > (actually, clip views) is that the bounds coordinate space inside them > is independent of the size of the view itself. If you start drawing > constraints between the contents of the scroll view and its enclosing > clip view, you are violating that principle. And it winds up being a > moot point because -[NSScrollView tile] just calls -setFrame: directly > on the clip view.
I’m not doing that part with constraints, but with code. It’s working perfectly, except when a view has a maximum size. >> What I’m trying to find is the upper limit on the width and height >> according to the current set of constraints at runtime, when I don’t >> necessarily know what the subviews or their constraints are. > > I do not believe this question makes sense from the perspective of the > layout system. Sure it does. For example, take a view that has a maximum width, per its constraints, and make it the content view of an NSWindow. Now run the app and play around with resizing the window by dragging its edges. Notice how once you try to resize it to a width greater than the view’s maximum width, NSWindow stops resizing it any wider and keeps the width at the maximum. Somehow, NSWindow has figured out the maximum width of the view and adjusted its resize requests accordingly. How does it do that? Charles _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
