How Window Controllers Work

How Window Controllers Work

A controller object (in this case, NSWindowController) manages a window; this object is usually stored in a nib file. This management entails the following:

• Loading and displaying the window

• Closing the window when appropriate

• Customizing the window’s title

• Storing the window’s frame (size and location) in the defaults database

• Cascading the window in relation to other document windows of the application

A window controller can manage a window by itself or as a role player in the Application Kit’s document-based architecture, which also includes NSDocument and NSDocumentController objects. In this architecture, a window controller is created and managed by a “document” (an instance of an NSDocumentsubclass) and, in turn, keeps a reference to the document. For a discussion of this architecture, seeDocument-Based Applications Overview.

The relationship between a window controller and a nib file is important. Although a window controller can manage a programmatically created window, it usually manages a window in a nib file. The nib file can contain other top-level objects, including other windows, but the window controller’s responsibility is this primary window. The window controller is usually the owner of the nib file, even when it is part of a document-based application. Regardless of who is the file’s owner, the window controller is responsible for freeing all top-level objects in the nib file it loads.

For simple documents—that is, documents with only one nib file containing a window—you need do little directly with NSWindowController objects. The Application Kit will create one for you. However, if the default window controller is not sufficient, you can create a custom subclass of NSWindowController. For documents with multiple windows or panels, your document must create separate instances ofNSWindowController (or of custom subclasses of NSWindowController), one for each window or panel. An example is a CAD application that has different windows for side, top, and front views of drawn objects. What you do in your NSDocument subclass determines whether the default NSWindowController object or separately created and configured NSWindowController objects are used.

Window Closing Behavior

When a window is closed and it is part of a document-based application, the document removes the window’s window controller from its list of window controllers. This results in the deallocation of the window controller and the window, and possibly the deallocation of the NSDocument object itself. When a window controller is not part of a document-based application, closing the window does not by default result in the deallocation of the window or window controller. This is the desired behavior for a window controller that manages something like an inspector; you shouldn’t have to load the nib file again and re-create the objects the next time the user requests the inspector.

If you want the closing of a window to make both window and window controller go away when it isn’t part of a document, your subclass of NSWindowController can observe NSWindowWillCloseNotification or, as the window delegate, implement the windowWillClose: method and include the following line of code in your implementation:

[self autorelease];

As a consequence of autoreleasing itself, an NSWindowController object autoreleases its window as well as all other top-level objects in its nib file. In any case, a window controller should not get rid of its window until it ensures its own deallocation.