On Mar 16, 2013, at 8:57 PM, Chuck Soper <chu...@veladg.com> wrote: > > Is persistent layout ambiguity (for the documentView only) necessarily a > problem? My UI works fine. I don't see how having the documentView > ambiguous is causing a problem.
Yes, it's a problem. In my talk I reference a bug we had where, because layout was ambiguous during window setup, when we restored the window frame from user preferences, the subviews would be resized to zero and gain 0-size autoresizing mask constraints. Then the first -updateConstraints pass would happen for the window, and our newly-installed constraints would of course conflict with the automatically generated ones. > > I'll review your previous email and try to listen to your auto layout talk. > > Previously, I didn't call setTranslatesAutoresizingMaskIntoConstraints: on > my documentView. I just added a subview to documentView and called > setFrameSize: on the documentView. This worked great until I needed to > change the width of the documentView by dragging the mouse. I adopted the same hack for the same reason, and it worked fine until a month or so ago. Then I hit another ambiguous-layout-causes-unsatisfiable-constraints exception and resolved to fix the problem in a way that didn't violate NSClipView's expectations. > > I'm starting to seriously regret trying to use auto layout with > NSScrollView. I already have a quite a bit of of code that uses auto > layout within the subviews of my documentView. Lucky for you, poor saps like me have already done the hard work of figuring out the kinks. ;-) > >>> >>> >>> To pin the height of the documentView to its NSScrollView, I use the >>> following constraint: >>> NSDictionary * scrollViewsDict = >>> NSDictionaryOfVariableBindings(documentView); >>> >>> [scrollView addConstraints: [NSLayoutConstraint >>> constraintsWithVisualFormat: >>> @"V:|[documentView]|" options: 0 metrics: nil views: >>> scrollViewsDict]]; >> >> You have not shown any other vertical constraints for your subviews. If >> all you have are the ">= 70" constraints, there are infinitely many >> solutions to your document view height. That would be the source of your >> ambiguity. > > I neglected to mentioned that in my documentView's updateConstraints > method that I add @"V:|[subview(>=70)]|" to self for each subview. Okay, so I was wrong about the source of your ambiguity. But that's because I misread your description upon re-reading and thus second-guessed my original explanation. > > I thought the source of the ambiguity was related to not setting width > constraint for the documentView. I do set each subview with > @"H:[subview(==120)]" and specify the documentView layout with > @"H:|[subview1][subview2][subview3]|" but I'm not sure that's enough. You've specified the width of your documentView alright, but not its position. Since there are infinite possible answers for your documentView's frame.origin, the constraint solver consistently picks 0 for all free variables when you click “Exercise Ambiguity.” It just so happens that this is the desired documentView position for correct scrolling behavior. So the short-term fix is to add leading- and bottom-margin constraints relating your documentView to its superview. But the real fix is to bite the bullet and adopt the adaptor view technique I described in my previous email. NSClipView really wants to use -setFrame: on your documentView, so you should let it. --Kyle Sluder _______________________________________________ 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
