Re: Quickie about constraints
Re: Quickie about constraints
- Subject: Re: Quickie about constraints
- From: Roland King <email@hidden>
- Date: Mon, 18 Aug 2014 07:55:26 +0800
> On 18 Aug 2014, at 7:18 am, Graham Cox <email@hidden> wrote:
>
>
> On 16 Aug 2014, at 4:10 pm, Kyle Sluder <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden