How Window Controllers Work
A controller object (in this case, an instance of the NSWindowController
class) 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 participant in AppKit’s document-based architecture, which also includes the NSDocument
and NSDocumentController
classes. In this architecture, a window controller is created and managed by a document (an instance of an NSDocument
subclass) and, in turn, keeps a reference to the document. For a discussion of this architecture, see Document-Based App Programming Guide for Mac.
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.
For simple documents—that is, documents with only one nib file containing a window—you need do little directly with NSWindowController
objects. AppKit creates 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 of NSWindowController
(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 system deallocating the window controller and the window, and possibly 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 the NSWindowWillCloseNotification
notification or, as the window delegate, implement the windowWillClose:
method.
Copyright © 2002, 2009 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2009-11-27