The salient facts about key events, as presented in “Key Events” and “The Path of Key Events,” are the following:
Key events are of three specific types (NSEventType), each of which is associated with an NSResponder method:
Event-type constant | Event method |
|---|---|
The flagsChanged: method can be useful for detecting the pressing of modifier keys without any other key being pressed simultaneously. For example, if the user presses the Option key by itself, your responder object can detect this in its implementation of flagsChanged:.
Most key events—that is, those representing characters to be inserted as text—are dispatched by the NSWindow object associated with the key window to the first responder.
If the first responder does not handle the event, it passes the event up the responder chain (see “The Responder Chain”).
The delivery path of a key event varies according to whether the event represents a character, a key equivalent, a keyboard action, or a keyboard interface control command. The global application object (NSApp) first looks for key equivalents and then keyboard interface control commands and handles them specially (see “The Path of Key Events” for details). If the event is neither of these, it dispatches it to the NSWindow object representing the key window, which in turn dispatches the event to the first responder in a keyDown: message.
The responder object determines what the key event represents and handles it appropriately. At this point, the key event could represent any one of the following things:
A keyboard action, which is a key or key combination bound to an action-message selector in a key bindings dictionary (see “Key Bindings”).
An application-specific command or action (one not using the key bindings dictionary)
A character or characters to insert into text
See “Overriding the keyDown: Method” for more information.
As with key event messages, a keyboard action message is passed up the responder chain if the first responder does not handle it.
Last updated: 2007-03-16