Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Yes, this can be done.</p> <p>If you set a view's <code>translatesAutoresizingMaskIntoConstraints = YES</code>, then calls to <code>setFrame:</code> are automatically translated at runtime into layout constraints based on the view's current <code>autoresizingMask</code>. This lets you mix frame-based layout with constraint-based layout.</p> <p>For instance you could use Auto Layout to define the layout of all of the subviews of a view, but still call <code>setFrame:</code> to set the size and position of the view itself. From your perspective, you're doing layout with a mix of Auto Layout and direct frame manipulation. But the system is actually using constraints to handle everything. </p> <p>However, there is one big caveat about using <code>translatesAutoresizingMaskIntoConstraints</code>.</p> <p>When you do this, <em>you still need to make sure that these automatic constraints can be satisfied with the rest of your constraints</em>.</p> <p>So, for instance, suppose there are already constraints that determine the size and position of your view, and then you <em>also</em> set <code>translatesAutoresizingMaskIntoConstraints = YES</code> and called <code>setFrame:</code>. The call to <code>setFrame:</code> will generate new constraints on the view, which will probably conflict with the already existing constraints.</p> <p>(In fact, this error happens often. If you ever see a log message complaining about conflicting constraints, and one of those constraints is a <code>NSAutoresizingMaskLayoutConstraint</code>, then what you're seeing is a conflict with an automatic constraint. This is an easy mistake, because <code>translatesAutoresizingMaskIntoConstraints = YES</code> is the default value, so if you're configuring constraints in code you need to remember to turn it off if you don't want these automatic constraints.)</p> <p>In contrast, suppose again that there are already existing constraints that determine the size and position of your view, but then you set <code>translatesAutoresizingMaskIntoConstraints = NO</code> before you call <code>setFrame:</code>. In this case, your <code>setFrame:</code> calls would not produce new constraints, so there would be no conflict <em>between separate constraints</em>. However, in this case, there is still a "conflict" <em>between the constraints and the frame value you set</em>. At the next time Auto Layout is invoked, it would see the already existing constraints on the view, calculate the frame value which they require, and set the frame to the required value itself, clobbering the value you set manually.</p> <p>For more details, check out the section "Adopting Auto Layout" in Apple's <a href="https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Introduction/Introduction.html">Cocoa Auto Layout Guide</a>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload