Customizing Your View’s Layout

Layout is an important feature of Interface Builder. Users need to be able to position views and controls visually to make sure they line up properly and in accordance with the Aqua style guidelines. To help with alignment, Interface Builder provides dynamic guides that become visible when a view or control is in close proximity to an appropriate boundary of another object.

By default, Interface Builder uses a view’s frame as the alignment boundaries for the view. This may be appropriate for some views but may not be for others. Many controls have frames that are actually bigger than the main visual component of the control. This is often done to allow room for drawing shadows and other visual effects. Figure 6-1 shows several controls along with their actual frame rectangles, which are in blue. In most cases, the frame rectangles are slightly larger than the drawn portion of the control.

Rather than using a view’s frame rectangle for alignment, it is generally preferable to align views and controls by other means. Most commonly, you would align controls according to the boundaries of their main visual component. For controls with text, you might also want to align the control using the baseline of the text. Figure 6-2 shows the frame rectangles of a set of controls but also shows the inset rectangles and custom baselines of those controls in red. For the user, it makes more sense to use these boundaries to align controls.

In Interface Builder, you can provide custom baselines and inset values for each of your custom views. You do this by overriding category methods defined on the NSView class in the Interface Builder Kit framework. Information about the information to provide in these methods is in the sections that follow.

- (IBInset)ibLayoutInset

{

    IBInset inset = {8, 6, 6, 4};

    return inset;

}

Implementing a Design-Time Container View

If your view is capable of acting as a container view, you should override the ibDesignableContentView method in your custom view. Returning a valid view object from this method tells Interface Builder to treat that view as a container at design time and let the user add child views to it. For most views, you would simply override this method and return self, to indicate that the current view is the container, but this need not be the case. If your main view is not the view you want to use as the container, you could return an associated subview. For example, a scroll view contains a clip view, which in turn contains the document view to be scrolled. In that situation, the scroll view would return its clip view object as the container view.

Although container views allow their children to be moved and resized freely for the most part, you can alter this behavior by overriding the ibIsChildViewUserMovable: and ibIsChildViewUserSizable: methods in your container view. You should only need to override these methods if allowing the user to move or resize child views would cause problems for your view. For example, scroll views do not allow users to move or resize their contained scrollers. The position and size of the scrollers remains fixed based on the scroll view’s frame and cannot be changed by the user at design time.

For more information about these methods see NSObject Interface Builder Kit Additions Reference and NSView Interface Builder Kit Additions Reference.

Exposing Embedded Child Objects

In each document, Interface Builder distinguishes between objects that can be selected and inspected by the user and those that are simply there in a supporting role. Objects that can be selected and inspected are considered “first-class” objects and are the only objects users actually see in a document. Supporting objects are present in the nib file but cannot be configured by the user and are generally not visible. Both first-class objects and supporting objects are saved as part of the resulting nib file.

For each library entry, Interface Builder exposes only the represented object of the entry as a first-class object by default. (For more about the structure of library entries, see Configuring a Library Object Template.) The actual implementation of a represented object can have any number of associated child objects, however, all of which are relegated to supporting roles by default. To change child objects into first-class objects, you expose them to Interface Builder by overriding the ibDefaultChildren method of their nearest parent object.

The ibDefaultChildren method simply returns a list of objects to expose as first-class children of the receiver. For each exposed child, Interface Builder calls the child’s own ibDefaultChildren method to give that child a chance to expose its own children. When exposing child objects, give careful consideration to which objects you want to expose. Views in a view hierarchy commonly expose configurable child views. They may also expose cell objects, which although not views do contain configurable attributes, outlets, and actions. It is rare for non-view objects to expose child objects—that is, you typically would not expose any child objects from a controller object.

The sections that follow discuss some of the ways a parent view can manipulate the information surrounding its child objects. For more information about implementing the ibDefaultChildren method or any of the methods discussed in the following sections, see NSObject Interface Builder Kit Additions Reference.

- (BOOL)ibCanRemoveChildren:(NSSet *)children {

    BOOL deny = [children containsObject:[self menu]];

    return deny ? NO : [super ibCanRemoveChildren:children];

}

- (void)ibRemoveChildren:(NSSet *)children {

    if ([self formatter] && [children containsObject:[self formatter]]) {

        [self setFormatter:nil];

    }

    [super ibRemoveChildren:children];

}

Configuring Objects at Design Time

Interface Builder sends notifications to your custom objects whenever they are added to or removed from a user’s document. You can implement the ibAwakeInDesignableDocument:, ibDidAddToDesignableDocument: and ibDidRemoveFromDesignableDocument: methods in your custom object to receive these notifications. You might use these notifications to perform additional configuration steps involving other objects in the document. For example, you could create or remove connections between your custom objects and the File’s Owner, First Responder, or Application object of the document.

For more information about these notification methods, see NSObject Interface Builder Kit Additions Reference.