You can add your own triggers related to keyboard focus by defining a custom property trigger. The XAML fragment below defines a new Style element that changes the Background of the control when IsKeyboardFocused is true.

If you have an application with several TextBox controls, you’ll notice that the TextBox that currently has focus “lights up” by drawing a light blue border around the edge of the TextBox.

The TextBox draws the blue border by setting up a trigger in its control template. You can see the body of the control template by right-clicking the TextBox in Visual Studio from the design surface and selecting Edit Template, followed by Edit a Copy.

When you do this, you’ll be asked to give the new copy a name (e.g. TextBoxStyle1). You’ll then get the full body of the template in the XAML document.

Looking at this template, you’ll see a Trigger on the IsKeyboardFocused property that sets the value of the BorderBrush on a Border element. It sets it to a static resource, which is defined earlier in the template (to a light blue color).

Events raised by user interface elements that are related to keyboard focus are:

PreviewLostKeyboardFocus (tunneling)

PreviewGotKeyboardFocus(tunneling)

LostKeyboardFocus (bubbling)

GotKeyboardFocus (bubbling)

When keyboard focus changes from one control to another, the events fired by the controls are in the order listed above.

Suppose that we have two TextBox controls in a StackPanel, which is contained within a Window. If the first TextBox has keyboard focus and the user causes the second TextBox to receive focus, the sequence of events is as follows:

If we attach an event handler to the main Window for the TextInput event and use the handler to log information about the event, we can start typing after the window comes up and see that the Window is getting TextInput events based on what we type. Nothing is rendered to the screen, but our logging indicates that TextInput events are being fired, with the main window as their source.

In WPF, controls that a user interacts with are typically able to get keyboard focus. (Focusable property is true). This includes controls that supported text-based input, like the TextBox. But it also includes controls that the user typically interacts with using the mouse, rather than the keyboard.

Controls that cannot get keyboard focus are ones like the Label that the user does not interact with.

For example, a user will typically use only the mouse when interacting with a Button or a CheckBox, but both of these controls can get keyboard focus. This is because the user can also interact with these controls using the keyboard. (E.g. Enter key to “click” a Button, or Spacebar to toggle a CheckBox).

The example below uses code to detect which control has focus. Note that as we tab through the controls, the TextBox controls get focus, as well as the Button and the CheckBox.

A control has keyboard focus if it can accept input from the keyboard. The sample code below is a working app that lets us experiment with keyboard focus by setting a Label to indicate which control has focus.

XAML includes some controls and defines a GotKeyboardFocus for the top-level Window.