.. and I finally found the one piece of the autolayout adoption guide which made me think back in the day I could use setFrame: and it would all work nicely.
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AdoptingAutoLayout/AdoptingAutoLayout.html#//apple_ref/doc/uid/TP40010853-CH15-SW1 <https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AdoptingAutoLayout/AdoptingAutoLayout.html#//apple_ref/doc/uid/TP40010853-CH15-SW1> This tells you that not only are constraints set up for you based on the autoresizing mask but they are also adjusted for you as you call setFrame: That I never got to work, at least on iOS I never got it to work. By the time I got to OSX, I'd given over the dark side and it was constraints all the way down. > On 18 Aug 2014, at 7:55 am, Roland King <r...@rols.org> wrote: > > >> On 18 Aug 2014, at 7:18 am, Graham Cox <graham....@bigpond.com> wrote: >> >> >> On 16 Aug 2014, at 4:10 pm, Kyle Sluder <k...@ksluder.com> wrote: >> >>> Not sure if you’ve got this backwards, or are unaware of a certain >>> frameworks bug. >>> >>> Views whose translatesAutoresizingMaskIntoConstraints property is set to >>> YES can be positioned via -setFrame:. Views whose property is set to NO >>> must be positioned via constraints. >> >> >> Can you provide some more info on this? It certainly has me confused - the >> name of that method *appears* to hint that by passing NO you're telling the >> system you will handle a view's layout, so skip it when evaluating >> constraints. If that's not what it does, it is very badly named - no doubt >> it made sense to someone at the time, but when approaching constraints for >> the first time, it's very misleading. >> >> My assumption about this method is that it permits the translation of masks >> once, when the view is set up, rather than each time the constraints have to >> be solved. If it is the latter however, that may be why the sense of its >> parameter appears to be back to front. > > > Springs and struts are simple enough (constrained enough?) that if you have a > view using them, explicitly or by default, those same spring/strut > relationships can always be expressed as constraints and can be > auto-generated. translatesAutoresizingMaskIntoConstraints appeared when > autolayout appeared as a way for developers to opt-in to the constraint > system. If you are using constraints at all, you are using constraints > everywhere. So having that method return YES means when you are using > autolayout each such view will infer its own constraints from the old springs > and struts it would have used before autolayout thus completing the hierarchy > of constraints all the way up to the top window. Having > translatesAutoresizingMaskIntoConstraints allows you to add in new bits of > layout using explicit constraints and default the constraints in the old > stuff to do what it did before with springs and struts by filling in the > constraints for you. > > Or look at the flip side, might be easier. If you set up constraints in IB, > IB turns that flag to NO for those views. If you add a view into a layout in > code and you add constraints to it, you have to set it to NO in code to sto > the view having 2 sets of constraints, the ones you set and the ones which > are inferred from the fact you're running in 'autolayout' mode. > >> >>> That means that if a layout pass happens to occur at any point, your view >>> will effectively disappear as its frame is set to NSZeroRect. >> >> >> I do seem to have a situation where my view disappears when I try to resize >> it via -setFrame:, though not when the window is resized. I don't want that >> to happen, so what do I do to stop the constraints system from even touching >> it? > > You can't - if autolayout is on, it's on, the constraint system owns > everything and retains the right to recalculate the entire system of > equations at any point and call setFrame: on any piece of your view hierarchy > it deems needs messing with. > >> >> I've removed the constraints in IB and am now passing >> -setTranslatesAutoreszingMaskIntoConstraints:YES as suggested, and my view >> isn't disappearing any more. -setFrame: also seems to be working, so this >> might be all I need to do. I'm a bit reluctant to call it solved though, >> because my understanding of what's going on is no clearer. In fact, the >> opposite. > > After many sleepless nights in the early days of adopting autolayout I > consider autolayout and setFrame: to be mutually exclusive. it may be > possible at higher view levels to do constant ends-around the constraint > system and get away with it but I stopped trying. My recollection is also > that many of the autolayout videos and possibly some of the documentation > have the removal of setFrame: as one of the steps in adopting autolayout. > _______________________________________________ _______________________________________________ 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
