Learn Objective-C on the Mac - Mark Dalrymple [101]
Standard System Panels
In addition to the generic window classes that are meant for you to fill with your own views and controls, Cocoa includes some specialized window subclasses for use in your applications. These are meant to meet the needs of a wide variety of applications, so using them gives you a lot of functionality for free, and at the same time provides your users with familiar interfaces that they’ve probably used in other applications.
The Color Panel
First let’s take a look at NSColorPanel. This panel provides an interface that allows the user to select a color. We’re going to use the color panel to set the color of a piece of on-screen text, by implementing a method in our controller class that’s called whenever the user selects a color in the color panel.
If you’re running Snow Leopard, Xcode will have created a class called WindowLabAppDelegate for you. Otherwise, in Xcode, make a new Objective-C class file called WindowLabAppDelegate.m, along with its matching .h file. We’re going to add an outlet called title and an action called showColorPanel:, as seen here:
The showColorPanel: method will be called by a simple button click in our GUI, which we’ll configure in Interface Builder. But the changeColor: method will be called whenever the user clicks on a color in the color panel, even though there won’t be any direct connection between the color panel and our code. This bit of “magic” works thanks to a Cocoa concept called the responder chain (see sidebar).
THE RESPONDER CHAIN
The responder chain is an ad hoc collection of objects, gathered on the fly when necessary during the life of an application, that can be queried to see if they implement a particular action. This lets certain actions be configured in a generic way, so that at runtime they will be invoked on the object that makes most sense at the time. The chain is arranged in order of specificity, starting with the object that is “nearest” to the action, and continuing along toward the most generic. Configuring an object to use the responder chain is done in Interface Builder by connecting to an action on the nib’s First Responder icon, which is nothing more than a proxy for the first object in the responder chain that says, at runtime, “Yes I can” when asked if it implements a particular method.
This is all made somewhat more confusing by the fact that each window has its own notion of a “first responder,” which is typically the control or view that the user last interacted with (thereby making it a likely candidate for receiving key-presses, and the like).
Let’s try to clarify this with an example. Consider the case of a button whose target/action is configured to call a method called showThing: on the First Responder. When a user clicks the button, each of a list of objects will be asked, in order, if they implement a showThing: method, right up until one of them answers YES, at which point that object’s showThing: method is called, and the responder chain’s work is done. Here’s an example of what the responder chain can look like:1. The window’s “first responder” (the view that’s currently in focus and accepting keyboard input), its superview, the superview’s superview, and so on, all the way up the view hierarchy within the window
2. The window itself
3. The window’s delegate
4. The application object, NSApp
5. The application object’s delegate
The responder chain may contain additional objects as well, especially if you’re working on a Document-based application, in which case open documents and their controller’s will have a spot in the chain as well. More on that in Chapter 11.
As soon as any one of those objects says it implements showThing:, then the method is called on that object, and the search is over.
Now go to Interface Builder, where MainMenu.xib