none
AccessKey Pressed Event Raised when pressing access key without ALT

    Question

  •  

    We have defined an access key on a label, which gives focus to a textbox.

    We have a second readonly textbox on the same user control.

     

    When clicking inside the readonly textbox and pressing the access key without ALT (e.g. L instead of ALT + L) the focus change is done anyway.

     

    Is it possible to disable this behaviour, i.e. is it possible to ensure, that the access key is only working when pressed together with ALT?

     

    The following xaml shows the issue:

     

    <Window x:Class="Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    SizeToContent="Height"

    Width="300" WindowStartupLocation="CenterScreen"

    >

      <StackPanel Orientation="Vertical"

        <TextBox IsReadOnly="True" Text="ReadOnly - give focus and press l" />

        <Label Content="_Label:Target="{Binding ElementName=box}"/>

        <TextBox x:Name="box" />

      </StackPanel>

    </Window>

    Friday, October 05, 2007 7:42 AM

Answers

  •  

    Menu and ToolBar menmonics work without pressing Alt key. We decided that we will have uniform behavior in all cases so access key work withour pressing Alt key.

    I understand that this is not in parity with Forms and we will consider this issue and change the behavior in the next version.

     

    For now as a workaround you can redister a class handler for all AccessKeyPressed events and handle the event if Alt key is not pressed.

     

    EventManager.RegisterClassHandler(typeof(UIElement), AccessKeyManager.AccessKeyPressedEvent, new AccessKeyPressedEventHandler(OnAccessKeyPressed));

    ...

    private static void OnAccessKeyPressed(object sender, AccessKeyPressedEventArgs e)

    {

    if (!e.Handled && e.Scope == null && (e.Target == null || e.Target == label))

    {

    // If Alt key is not pressed - handle the event

    if ((Keyboard.Modifiers & ModifierKeys.Alt) != ModifierKeys.Alt)

    {

    e.Target = null;

    e.Handled=true;

    }

    }

    Monday, October 08, 2007 11:13 PM

All replies

  • Hello, this is the desired behavior. If you type an access key on a Control that doesn’t receive keyboard input, the corresponding Control will get focus. To avoid this, you can handle PreviewGotKeyboardFocus event, and mark it as handled if you detect Alt key is not pressed.

     

    Monday, October 08, 2007 8:47 AM
  • Irritatingly, the behavior of a similar Forms application (with a Mnemonic) is such that nothing happens when the Alt key is not pressed.

    Thus, the "desired" behavior of a Forms vs a WPF application changes and this might be difficult to understand for users that are used to the way things worked in a Forms application.
    Monday, October 08, 2007 11:58 AM
  •  

    Menu and ToolBar menmonics work without pressing Alt key. We decided that we will have uniform behavior in all cases so access key work withour pressing Alt key.

    I understand that this is not in parity with Forms and we will consider this issue and change the behavior in the next version.

     

    For now as a workaround you can redister a class handler for all AccessKeyPressed events and handle the event if Alt key is not pressed.

     

    EventManager.RegisterClassHandler(typeof(UIElement), AccessKeyManager.AccessKeyPressedEvent, new AccessKeyPressedEventHandler(OnAccessKeyPressed));

    ...

    private static void OnAccessKeyPressed(object sender, AccessKeyPressedEventArgs e)

    {

    if (!e.Handled && e.Scope == null && (e.Target == null || e.Target == label))

    {

    // If Alt key is not pressed - handle the event

    if ((Keyboard.Modifiers & ModifierKeys.Alt) != ModifierKeys.Alt)

    {

    e.Target = null;

    e.Handled=true;

    }

    }

    Monday, October 08, 2007 11:13 PM
  • Thank you for reporting this issue.  Though this issue is under investigation, we will likely not have a fix available in .NET 4.0.  We have recorded your suggestion in an internal database and will be tracking it there to consider for a future release.  Thanks!
    Friday, June 05, 2009 9:10 PM
  •  

     

    This behavior is by design but causes a problem when you have, for example, a datagrid in a tab and the non-editing control for a column in the datagrid does not receive keyboard input but the editing control for that column does receive keyboard input. Select the tab, single click on that column in the grid's new row, and enter the access key for a different tab, without ALT pressed. The grid adds a new row, puts the row into edit mode, and enters the key press into the editing control in the new row. However, the access manager also sees the key and switches to the other tab on you. This is frankly wrong behavior.

    Saturday, December 18, 2010 5:00 AM
  • I've used the above and it works.  However, that prevented the default action for Enter and ESC.  So I inserted the following at the top of the method.

    if (Keyboard.IsKeyDown(Key.Enter) || Keyboard.IsKeyDown(Key.Escape)) return;

     

    Monday, January 31, 2011 7:28 PM