Learn Objective-C on the Mac - Mark Dalrymple [106]
This arrangement isn’t without complications, however. In a typical Windows application, you might have a number of different windows, each with its own menu, containing items that are only relevant to that window’s contents. While it’s technically possible to do something similar in a Mac OS X application, changing the structure of the menu as different windows are selected, this usage is frowned upon, and will probably bother some users, who on the Mac are quite accustomed to applications that behave in a consistent manner. Instead, you can implement a behavior that is fully supported and recommended: Enabling and disabling menu items based on the currently selected window (or, indeed, the currently selected object inside a window). In this section, we’re going to show you how to do this, but first we’re going to talk a bit about the system menus that are included with Cocoa and standard across most applications.
Standard Application Menu Items
Apple’s guidelines define a set of menus and menu items that should appear in most applications. Create a new application in Xcode, and name it MenuLab. This is where we’ll do some experimenting with menu items. Open the freshly created MainMenu.xib file, and double-click the MainMenu object to take a look at the predefined set of menus. This set contains top-level entries for the application itself, followed by File, Edit, Format, View, Window, and Help, each of which contains menu items of its own. Open up the Connections Inspector (⌘5) so that we can examine some of these items and see what they’re connected to. Just click around on each of the various menu items, and keep your eye on the Inspector after each click. There are a few exceptions, but most of the items are connected to the First Responder proxy that we talked about earlier. Soon you’ll see that by connecting a menu item to the First Responder, not only will the item call its action method in the most relevant object, it will also be automatically enabled and disabled based on the contents of the responder chain.
Your Own Menus
The standard menus contain a lot of functionality, everything from bringing up the app’s About Box to editing and formatting text, to dealing with windows, is all set up. However, many applications need some extra functionality, something that doesn’t seem right to attach to a window, or just takes up too much space in a window. One common way to address this is to add one or more additional top-level menu items, usually between the View and Window menus. For instance, the Finder has a Go menu in there, and Xcode has, by my reckoning, no less than five additional top-level menus: Project, Build, Run, Design, and SCM. In our application, we’ll get by with just one additional menu. In the last paragraph, we asked you to create a new Cocoa project called MenuLab. If you’re running Snow Leopard, the template used to create your new application already contains an app delegate class, and you can move along to the next heading. Otherwise, if you’re on Leopard, configure the app delegate as follows: create a new Objective-C class named MenuLab_AppDelegate. Open up the new project’s MainMenu.xib, and set up the app delegate: Drag an NSObject out of the Library to the main nib window, set its class to MenuLab_AppDelegate using the Identity Inspector, and connect the application’s delegate outlet to this new instance.
Enabling/Disabling With Bindings
The first thing we’re going to do is set up a pair of menu items to control a boolean attribute in our app delegate. You could use these to control some sort of switch that affects an application-wide setting. In our case, we’ll create a property called turbo, which presumably makes everything