---

The Responder Chain

The responder chain is a linked series of responder objects to which an event or action message is applied. When a given responder object doesn’t handle a particular message, the object passes the message to its successor in the chain (that is, its next responder). This allows responder objects to delegate responsibility for handling the message to other, typically higher-level objects. The Application Kit automatically constructs the responder chain as described below, but you can insert custom objects into parts of it using the NSResponder method setNextResponder: and you can examine it (or traverse it) with nextResponder.

An application can contain any number of responder chains, but only one is active at any given time. The responder chain is different for event messages and action messages, as described in the following sections.

In this section:

Responder Chain for Event Messages
Responder Chain for Action Messages
Other Uses

Responder Chain for Event Messages

Nearly all event messages apply to a single window’s responder chain—the window in which the associated user event occurred. The default responder chain for event messages begins with the view that the NSWindow object first delivers the message to. The default responder chain for a key event message begins with the first responder in a window; the default responder chain for a mouse or tablet event begins with the view on which the user event occurred. From there the event, if not handled, proceeds up the view hierarchy to the NSWindow object representing the window itself. The first responder is typically the “selected” view object within the window, and its next responder is its containing view (also called its superview), and so on up to the NSWindow object. If an NSWindowController object is managing the window, it becomes the final next responder. You can insert other responders between NSView objects and even above the NSWindow object near the top of the chain. These inserted responders receive both event and action messages. If no object is found to handle the event, the last responder in the chain invokes noResponderFor:, which for a key-down event simply beeps. Event-handling objects (subclasses of NSWindow and NSView) can override this method to perform additional steps as needed.

Responder Chain for Action Messages

For action messages, the Application Kit constructs a more elaborate responder chain that varies according to two factors:

• Whether the application is based on the document architecture and, if it isn't, whether it uses NSWindowController objects for its windows

• Whether the application is currently displaying a key window as well as a main window

Action messages have a more elaborate responder chain than do event messages because actions require a more flexible runtime mechanism for determining their targets. They are not restricted to a single window, as are event messages.

The simplest case is an active non-document-based window that has no associated panel or secondary window displayed—in other words, a main window that is also the key window. In this case, the responder chain is the following:

1. The main window’s first responder and the successive responder objects up the view hierarchy

2. The main window itself

3. The main window’s delegate (which need not inherit from NSResponder)

4. The application object, NSApp

5. The application object’s delegate (which need not inherit from NSResponder)

This chain is shown graphically in Figure 1-8.

As this sequence indicates, the NSWindow object and the NSApplication object give their delegates a chance to handle action messages as though they were responders, even though a delegate isn’t formally in the responder chain (that is, a nextResponder message to a window or application object doesn’t return the delegate).

When an application is displaying both a main window and a key window, the responder chains of both windows can be involved in an action message. As explained in "Window Layering and Types of Window," the main window is the frontmost document or application window. Often main windows also have key status, meaning they are the current focus of user input. But a main window can have a secondary window or panel associated with it, such as the Find panel or a Info window showing details of a selection in the document window. When this secondary window is the focus of user input, then it is the key window.

When an application has a main window and a separate key window displayed, the responder chain of the key window gets first crack at action messages, and the responder chain of the main window follows. The full responder chain comprises these responders and delegates:

1. The key window’s first responder and the successive responder objects up the view hierarchy

2. The key window itself

3. The key window’s delegate (which need not inherit from NSResponder)

4. The main window’s first responder and the successive responder objects up the view hierarchy

5. The main window itself

6. The main window’s delegate (which need not inherit from NSResponder)

7. The application object, NSApp

8. The application object’s delegate (which need not inherit from NSResponder)

As you can see, the responder chains for the key window and the main window are identical with the global application object and its delegate being the responders at the end of the main window's responder chain. This design is true for the responder chains of the other kinds of applications: those based on the document architecture and those that use an NSWindowController object for window management. In the latter case, the default main-window responder chain consists of the following responders and delegates:

1. The main window’s first responder and the successive responder objects up the view hierarchy

2. The main window itself

3. The main window’s delegate

4. The window's NSWindowController object (which inherits from NSResponder)

5. The application object, NSApp

6. The application object's delegate

Figure 1-9 shows the responder chain of non-document-based application that uses an NSWindowController object.

For document-based applications, the default responder chain for the main window consists of the following responders and delegates:

1. The main window’s first responder and the successive responder objects up the view hierarchy

2. The main window itself

3. The main window’s delegate.

4. The window's NSWindowController object (which inherits from NSResponder)

5. The NSDocument object (if different from the main window’s delegate)

6. The application object, NSApp

7. The application object's delegate

8. The application's document controller (an NSDocumentController object, which does not inherit from NSResponder)

Figure 1-10 shows the responder chain of a document-based application.

Other Uses

The responder chain is utilized by three other mechanisms in the Application Kit:

• Automatic menu enabling: In automatically enabling and disabling a menu item with a nil target, an NSMenu searches different responder chains depending on whether the menu object represents the application menu or a context menu. For the application menu, NSMenu consults the full responder chain—that is, first key, then main window—to find an object that implements the menu item’s action method and (if it implements it) returns YES from validateMenuItem:. For a context menu, the search is restricted to the responder chain of the window in which the context menu was displayed, starting with the associated view.

  For more on automatic menu enabling, see “Enabling Menu Items".

• Services eligibility: Similarly, the Services facility passes validRequestorForSendType:returnType: messages along the full responder chain to check for objects that are eligible for services offered by other applications.

  For further information, see System Services.

• Error presentation: The Application Kit uses a modified version of the responder chain for error handling and error presentation, centered upon the NSResponder methods presentError:modalForWindow:delegate:didPresentSelector:contextInfo: and presentError:.

  For more information on the error-responder chain, see Error Handling Programming Guide For Cocoa.

---