Keyboard and Ink Input with WPF
(Page 1 of 4 )
In this third part of a five-part series that walks you through the input handling mechanisms available in WPF, you will learn about keyboard and printer-related input. We will also start talking about commands. This article is excerpted from
Programming WPF, Second Edition, written by Chris Sells and Ian Griffiths (O'Reilly, 2007; ISBN: 0596510373). Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.
Keyboard Input
The target for mouse input is always the element currently under the mouse, or the element that has currently captured the mouse. This doesn’t work so well for keyboard input—the user cannot move the keyboard, and it would be inconvenient to need to keep the mouse directly over a text field while typing. Windows therefore uses a different mechanism for directing keyboard input. At any given moment, a particular element is designated as having the focus, meaning that it acts as the target for keyboard input. The user sets the focus by clicking the control in question with the mouse or stylus, or by using navigation keys such as the Tab and arrow keys.
TheUIElementbase class defines anIsFocusedproperty, so in principle, any user interface element can receive the focus. However, theFocusableproperty determines whether this feature is enabled on any particular element. By default, this is true for controls, and false for other elements.
Table 4-2 shows the keyboard input events offered by user interface elements. Most of these items use tunnel and bubble routing for the preview and main events, respectively.
Table 4-2. Keyboard input events
Event | Routing | Meaning |
PreviewGotKeyboardFocus, GotKeyboardFocus | Tunnel, Bubble | Element received the keyboard focus. |
PreviewLostKeyboardFocus, LostKeyboardFocus | Tunnel, Bubble | Element lost the keyboard focus. |
GotFocus | Bubble | Element received the logical focus. |
LostFocus | Bubble | Element lost the logical focus. |
PreviewKeyDown, KeyDown | Tunnel, Bubble | Key pressed. |
PreviewKeyUp, KeyUp | Tunnel, Bubble | Key released. |
PreviewTextInput, TextInput | Tunnel, Bubble | Element received text input. |
Strictly speaking, theTextInputevent is not caused exclusively by keyboard input. It represents textual input in a device-independent way, so this event can also be raised as a result of ink input from a stylus.
As Table 4-2 shows, WPF makes a distinction between logical focus and keyboard focus. Only one element can have the keyboard focus at any given instant. Often, the focus will not even be in your application—the user may switch to another application. However, applications typically remember where the focus was so that if the user switches back, the focus returns to the same place as before. WPF defines the logical focus concept to keep track of this: when an application loses the keyboard focus, the last element that had the keyboard focus retains the logical focus. When the application regains the keyboard focus, WPF ensures that the focus is put back into the element with the logical focus.
Next: Keyboard State >>
More .NET Articles
More By O'Reilly Media
|
 This article is excerpted from Programming WPF, Second Edition, written by Chris Sells and Ian Griffiths (O'Reilly, 2007; ISBN: 0596510373). Check it out today at your favorite bookstore. Buy this book now.
|
|
