When the user presses a key, a series of events is launched to handle that action. Let's follow the bits through the system after the user presses a key on the keyboard.
When the user presses a key on the keyboard, the entity responsible for
recognizing this action is the Input Server add-on for the keyboard
device on which the key was pressed. The add-on uses the current keymap
(which it has obtained by calling
get_key_map()
)
to map the keycode to the character.
The add-on then constructs a
B_KEY_DOWN
or B_UNMAPPED_KEY_DOWN
BMessage
,
containing both the raw keycode and the actual characters generated by
the key, and sends the message to the Application Server by calling the
BInputServerDevice::EnqueueMessage()
function.
The Aplication Server receives the message from the Input Server add-on and decides what to do with it. If the key pressed is something the Application Server traps, like a workspace change keystroke, it gets handled internally.
Otherwise, the Application server locates the active window and passes
the BMessage
along to its
BWindow::DispatchMessage()
function.
The
BWindow::DispatchMessage()
function receives the
BMessage
from the
Application Server, and intercepts some keys (like menu shortcuts and the
Command+W
close window sequence). If it's not a key the
BWindow
class (or
derived class) wants to intercept, DispatchMessage()
passes the message along to the currently focused view's
BView::MessageReceived()
function.
The message finally arrives at the view that's currently focused in the
active window. This view's
MessageReceived()
function processes the keypress in whatever way it wants to.
Likewise, when the key is released, a
B_KEY_UP
or B_UNMAPPED_KEY_UP
event
is sent through this same route.