Debugging

It may be obvious which view has the problem; if it is not, you may find it helpful to use the NSView method _subtreeDescription to create a textual description of the view hierarchy. (The _subtreeDescription method is not public API; it is, however, permissible to use for debugging purposes.)

(The Auto Layout instrument may be included with the developer tools in the future, but is currently provided as sample code in a template—see Cocoa Autolayout Demos).

To get the constraints affecting a particular view, use constraintsAffectingLayoutForOrientation:. You can then inspect the constraints in the debugger. They are printed using the visual format notation. If your views have identifiers (see identifier (NSView)), they print out using the identifier in the description, like this:

<NSLayoutConstraint: 0x400bef8e0 H:[refreshSegmentedControl]-(8)-[selectViewSegmentedControl] (Names: refreshSegmentedControl:0x40048a600, selectViewSegmentedControl:0x400487cc0 ) >

otherwise the output looks like this:

<NSLayoutConstraint: 0x400cbf1c0 H:[NSSegmentedControl:0x40048a600]-(8)-[NSSegmentedControl:0x400487cc0]>

Here’s an example of visualizing the constraints affecting the find field’s horizontal layout:

When you click a constraint, it is printed in the console. In this way you can you can determine which is which, and typically identify which is incorrect.

At this point you may be informed that the layout is ambiguous (see “Handling Ambiguity”).

Sometimes, once you have identified the incorrect constraint, you will know what to do to fix it.

If this is not the case then, in Instruments, search for the pointer of the constraint (or some of its description). This will show you interesting events in that constraint’s lifecycle—its creation, modification, installation into windows, and so on. For each of these you can see the backtrace where it happened. Find the stage at which things went awry, and look at the backtrace. This is the code with the problem.