Learn Objective-C on the Mac - Mark Dalrymple [104]
In Xcode, make a new class in the WindowLab project called NotSoEasyWindowController by selecting File➤New File... from the menu and choosing to create an NSWindowController subclass. Because we’re making our own class here, we can build in the name of the nib file so that anyone using this class only needs to know about the class, not the name of the nib file itself. We can also make things even easier for callers: assuming that anyone who creates an instance of this class wants to load the nib file, let’s build the call to window right into the init method. Do this by creating the following init method:
That’s the recommended form of the standard init method, in which we call another init method in the superclass, do work specific to our instance if it succeeds, and finish up by returning a pointer to self.
With that in place, let’s add a small bit of functionality to our window controller class, so that after our nib file is created, we can make sure that our window is connecting up with it as it should: A simple method that makes the computer beep when it’s called. Add the following method declaration and definition to the new class’s .h and .m files:
While you’re still in Xcode, add another method to the WindowLabAppDelegate class:
You’ll also need to add the following #import directive at the top of WindowLabAppDelegate.m, so that the compiler knows about the new class when it’s compiling the app delegate:
Now switch over to MainMenu.xib in Interface Builder. Once again, make your window a bit taller, duplicate the last button, and name it “Not So Easy.” Then connect it to the app delegate’s loadNotSoEasy: action method.
Still in Interface Builder, make a new empty file, and save it as NotSoEasyWindow.xib. Drag a window out of the Library and title it “Not So Easy Window,” then drag a button onto the new window and title it “Beep.”
Now all that’s left to do is connect the button to the controller. In previous chapters, every controller we’ve created has been added to a nib file as a top-level object, but when you’re loading a nib file yourself, you can specify an object to be its “owner,” which in Interface Builder is represented by the File’s Owner object in the main nib window. NSWindowController, our controller’s parent class, already sets itself up as the owner of the nib file when it loads the file, but we still have to manually configure that in Interface Builder so that we can make use of it. Select the File’s Owner icon, and open the Identity Inspector (⌘6). At the top of this inspector, you can set the class of the object that you expect to be the file’s owner. By default it’s set to NSObject. Change it to NotSoEasyWindowController, then Control-drag from the new button you added, to the File’s Owner icon in the main nib window, and select the beep: method. Save your changes, switch to Xcode, Build & Run, and you should see that your newest button lets you create windows that beep when you press their buttons, as seen in Figure 10-6.
Figure 10-6. These windows’ buttons will beep at you.
Modal Windows
Now we’re going to move on to a special kind of GUI item, the modal window. Everyone has used modal windows at one time or another, but if you’re new to desktop GUI programming, the term may be new to you. Basically, a modal window is one that puts your application in a particular “mode.” Specifically, a mode where it will only accept input through the controls on the modal window itself, and clicking anywhere else in the application will just make it beep at you. Because of their disruptive nature, modal windows should be used sparingly, in cases where the application can’t really move forward on its own without the user answering a question of some kinds (such as, “There are 5 open documents with unsaved changes, are you sure you want to quit?”). In cases where the information the app needs from the user is related