When using auto layout with a scroll view, you would want at least constraints to fix the position of the document view within the clip view. Usually, you fix it to the top-left.
If the document view should re-flow its content to fit the width of the clip view, like a text view or collection view (although those don't actually work this way), then the document view's trailing edge or width should be constrained to match the clip view's. If the document view should have a width independent of the scroll view's width, then you would *not* create trailing or width constraints. The clip view will observe the document view's size and update the scroll view accordingly. Same for the vertical orientation, although it's relatively uncommon for a document view to match its clip view's height and re-flow horizontally. For the problem where the document view is pinned to the bottom of the scroll view when the scroll view is large enough to show it its full height, there are two solutions: 1) as mentioned, use a subclass of NSClipView which is flipped; or 2) constrain the document view so its height is *at least* as tall as the clip view. The latter, of course, requires that the document view can stretch, possibly taller than strictly necessary from its subviews or contents. If it can't stretch, it will restrict the size of the clip view and scroll view. If the scroll view is "attached" to the window edges through a chain of constraints, that will actually fix your window size, too. You need to be careful when allowing the document view to stretch that you don't leave ambiguity. That is, don't just leave the height unconstrained. It should prefer a particular height at a lower priority than it prefers to be at least as tall as the clip view. Do not use intrinsicContentSize for size which is not, well, intrinsic to its content, where content is something like an image or text or data, but not subviews. The subviews and the constraints among them and with the document view should not influence the intrinsicContentSize. If you're trying to get behavior similar to content hugging priority and/or compression resistance priority, you can achieve those with inequality constraints of the desired priorities. For example, a constraint of the form "view height <= some constant @ 750 priority" is the rough equivalent of a vertical content hugging priority of 750. "View height >= some constant @ 250" is equivalent of a vertical compression resistance priority of 250. Etc. Of course, the scroll view itself can be constrained to its siblings or superview to determine its size. And you might want to use explicit width or height constraints, too. Possibly inequalities if you just want to enforce a minimum, for example. Regards, Ken _______________________________________________ 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
