• Choose a category
• All
• Classic-Fiction

Now, switch back to Interface Builder, where we’ll hook things up. First make your window a little taller. Then duplicate the button you’ve already got, name the new one “Show Font Panel,” and Ctrl-drag from it to the app delegate in the main nib window, connecting to the showFontPanel: action method. Save your work, go back to Xcode, and Build & Run. You can now change both the color and the font for the displayed text (see Figure 10-4).

Figure 10-4. Setting a label’s color and font

A Controller With a Nib of Its Own

Next, we’re going to demonstrate a simple pattern that occurs often in Cocoa development: making a controller class that loads its own nib file, becoming the “owner” of all the objects in the file. In every application we’ve created so far, all the GUI elements are contained inside the application’s single .nib file. This works well enough for simple applications, but it has its limits. For one thing, we only have one instance of each window and each controller in the nib. For another thing, the entire main nib file is loaded at once, when the application is starting up, and the more stuff you have in that nib, the slower and more memory-intensive the startup phase will be. Granted, on modern computers with several gigabytes of RAM, this may not be such a huge problem, but as a programmer it’s always good to try to not waste CPU and RAM recklessly. Finally, putting too many top-level objects (windows, controllers, and the like) into a single nib file makes life more difficult for you, the programmer, because it’s harder to see which controllers and windows belong together.

The solution to both of these problems is to distribute some of your GUI objects into other nib files, and mediate their use with controller classes that load the nibs. This technique is used by many Cocoa applications, which commonly split windows for preferences, documents, tools, and so on into separate nib files. The following sections will demonstrate two different ways of doing this, with increasing complexity.

Loading a Nib With NSWindowController

The first and easiest way is to use Cocoa’s NSWindowController class to load the nib file and be its owner. Start by going to the WindowLab project in Xcode, and adding a new method called loadEasyWindow: to the WindowLabAppDelegate class, as seen here:

In that method, we first initialize a new controller, telling it the name of the nib file to use, then we call its window method, which is what actually loads the nib file and displays the window.

Switch over to Interface Builder, and make a brand new file. Choose the Empty template, then drag out a window from the Library, and give the window the title Easy Window. Then save the file as EasyWindow.xib, in the same directory where WindowLab’s other nib file (MainMenu.xib) is located. Interface Builder will ask you if you want to add it to the WindowLab project; click the checkbox to confirm that you do.

Now switch back to MainMenu.xib in Interface Builder. Make your window a bit taller once more, and add another button below the others, this one a spaced a bit farther away so that it doesn’t appear to be involved with the text field from the previous exercises. Label the new button “Easy Window,” and connect it to the app delegate’s loadEasyWindow: action. Save, go back to Xcode, Build & Run, and you’ll see that your app’s new button lets you create new windows with each press of the button (see Figure 10-5).

Figure 10-5. Some easy windows

Each time, it’s actually creating a new NSWindowController instance, which loads a fresh copy of the nib file, including all objects inside of it. In this case all we have is a window, but you can put anything you like inside those nib files, including for example controller objects for accessing Core Data.

Subclassing NSWindowController

Of course, often you’ll need a bit of your own code in your controller class. You can easily subclass NSWindowController to suit your needs here