Learn Objective-C on the Mac - Mark Dalrymple [105]
The NSAlert Functions
The simplest modal windows available in Cocoa are the alert panels, which are created and run with a single function call. The function returns when the user clicks one of the buttons, and you can then check the return value to determine which of the buttons they clicked. Depending on how you call the function, there may be one, two, or three buttons presented for the user.
The most commonly used modal alert function is NSRunAlertPanel. It has a few variants called NSRunCriticalAlertPanel and NSRunInformationalAlertPanel, which are used for specific purposes specified in Apple’s user interface guidelines, but you can safely stick with NSRunAlertPanel. Each of these functions takes five or more parameters. First the title that appears at the top of the panel, then the full text to display, which presents some information or asks the user a question, then three strings (which may be nil) containing the button titles. Button titles left as nil will simply be undisplayed, except for the case where they’re all nil, in which case a single OK button is included on the panel.
To see some alert panels in action, implement the following method in WindowLabAppDelegate.m. Be sure to put a matching declaration in the .h file as well:
Test these out by going into MainMenu.xib, adding yet another button to your window (title it Run Modal Alerts), and connecting it to the app delegate’s runModalAlerts: action. Save, back to Xcode, Build & Run, and give it a whirl.
Open Panels and Save Panels
The other most commonly used modal panels in Cocoa are probably the ones for opening and saving files, NSOpenPanel and NSSavePanel. Using these panels is typically more than just a one-liner. You might first need to configure various options on the panel (for instance, whether it should allow the user to select multiple files for opening, or just one), then run the panel, check the return value (which indicates whether the user eventually clicked the open or save button, or canceled out), and then grab the resulting filenames from the panel. Note that these panels don’t actually do any file I/O, they just prompt the user for filenames and give you back the results.
To see an example of how this can work, consider the following method, which pretends to copy a file. This method uses an NSOpenPanel to prompt the user for the file to copy, then uses an NSSavePanel to let the user specify where the file should go:
Put that method into WindowLabAppDelegate.m, and create the matching declaration in the .h file. Then go back to MainMenu.xib in Interface Builder, and once again add a new button (call this one “Copy File”) and connect it to the new copyFile: action. Save your changes, go back to Xcode, Build & Run, and try out the new button. You’ll see a standard Open panel appear, followed by a standard Save panel. Note that the Save panel even has built-in functionality to warn you when you’re selecting an existing file, asking you if you really want to overwrite it (remember, it’s perfectly safe to confirm overwriting the file in this example, since we’re not actually copying anything).
It’s probably worth mentioning here the not-so-obvious fact that NSOpenPanel is actually a subclass of NSSavePanel. That means that if you can’t seem to find the functionality you’re expecting in NSOpenPanel’s documentation or header file, you may need to check out NSSavePanel as well.
System Menus
Now that you’ve seen some of the basics of how windows are used in Cocoa, let’s spend some time dealing with another ever-present feature of Mac OS X, the application menu. Unlike most other current operating systems, Mac OS X presents its menu at the top of the screen instead of at the top of each window. This arrangement has some nice upsides: screen real estate is saved, because instead of a horizontal strip taking space at the top of every