FocusManager Class

Definition

public ref class FocusManager sealed

/// [Windows.Foundation.Metadata.ContractVersion(Windows.Foundation.UniversalApiContract, 65536)]
/// [Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
/// [Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
class FocusManager final

[Windows.Foundation.Metadata.ContractVersion(typeof(Windows.Foundation.UniversalApiContract), 65536)]
[Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
[Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
public sealed class FocusManager

Public NotInheritable Class FocusManager

Inheritance

Object Platform::Object IInspectable FocusManager

Attributes

ContractVersionAttribute MarshalingBehaviorAttribute ThreadingAttribute

Windows requirements

Examples

Use TryMoveFocus to traverse between UI elements using the arrow keys.

private void Page_KeyUp(object sender, KeyRoutedEventArgs e)
{
   if (e.Key == Windows.System.VirtualKey.Up)
   {
      // Mimic Shift+Tab when user hits up arrow key.
      FocusManager.TryMoveFocus(FocusNavigationDirection.Previous);
   }
   else if (e.Key == Windows.System.VirtualKey.Down)
   {
      // Mimic Tab when user hits down arrow key.
      FocusManager.TryMoveFocus(FocusNavigationDirection.Next);
   }
}

Remarks

We recommend using the UIElement focus routed events instead of FocusManager events whenever possible.

FocusManager is intended for advanced scenarios where specific elements in an application do not receive bubbled events from a UIElement. For example, visual "overlay" objects such as Popup, Tooltip, or MenuFlyout that appear as part of the app UI but are actually their own focus scope and not part of the visual tree hierarchy. In the case of a Popup, this occurs when you programmatically set IsOpen to true and focus moves in and out of the popup.

Here's some basic markup to illustrate the example:

<Page …>
    <Grid …>
        <Popup …>
            <StackPanel Name="StackPanel3" …>
                <TextBlock Text="StackPanel3" />
                <Button Content="Button5" …/>
            </StackPanel>
        </Popup>
        <TextBlock Text="Grid" … />
        <StackPanel Name="StackPanel1" …>
            <TextBlock Text="StackPanel1" …/>
            <Button Content="Button1" …/>
            <Button Content="Button2" … />
        </StackPanel>
        <StackPanel Name="StackPanel2" …>
            <TextBlock Text="StackPanel2" …/>
            <Button Content="Button3" … />
            <Button Content="Button4" … />
        </StackPanel>
    </Grid>
</Page>

In this case, a Popup contains StackPanel3, which, in turn, contains Button5. When IsOpen is set to true and focus moves from Button1 to Button5, the LosingFocus and LostFocus events bubble up across the visual tree (StackPanel1, the Grid, and the Page get both these events). However, only StackPanel3 receives the subsequent GettingFocus and GotFocus events that bubble up from Button5 (Grid and Page do not, as they are not in a parent-child relationship with Popup).

An application can have multiple elements with logical focus (depending on the number of focus scopes). However, only one element in the application can have keyboard focus.

There can be multiple elements with logical focus, but only one element with logical focus per focus scope. An element with logical focus does not necessarily have keyboard focus, but an element with keyboard focus does have logical focus.

Version history

Methods

Events

Applies to

See also

• Keyboard interactions
• Focus navigation for keyboard, gamepad, remote control, and accessibility tools
• Programmatic focus navigation