All WPF context menus do not seem to handle highlighting items properly when a modifier key is held down
Asked Answered
O

1

6

It happens in all my WPF applications and Visual Studio 2019 (which is definitely WPF based) also exhibits this strange behavior:

Simply right click an item in the solution explorer while holding, say, the Control key and you should notice that the items highlighting will intermittently work if you keep holding the Control modifier.

At first I presumed that the grids and lists controls were still catching the modifier keys for the items selection but this issue also occurs with a context menu on a simple control like a standard button.

Is there a way to fix this glitch?


Here is a gif with wpf application context menu in action. First I move mouse normally, then with Ctrl hold down:

As you can see it glitch (is not highlighting menu items).

Oilskin answered 23/9, 2020 at 9:51 Comment(6)
Context menus are provided by Windows, not WPF. I don't see any difference when Ctrl is pressed.Phenica
Holding Ctrl and looking at context menu in my wpf application I can confirm menu item can be mouseovered without it being highlighted, which looks ugly . I wasn't aware about it, because I would never hold Ctr when using menu. Alt will just close menu. Shift has same issues. Why do you need modifier for menu? Create 2 menu items instead.Doreendorelia
Thank you for posting a gif showing the issue. I'm glad I'm not the only one who sees it happening. I need a second menu with special commands for more advanced users. A modifier key being pressed on right click doesn't seem to me like an unreasonable expectation.Oilskin
A modifier key being pressed on right click doesn't seem to me like an unreasonable expectation. Not sure that's correct. You usually have 2 kinds of users, they are either keyboard focused or mouse focused. When drawing or zooming you could combine both types of input, but it's not very user friendly to force this combined behavior on your advanced users. It would be better to define the menu items based on the user's level (beginner <> advanced). Eg through a setting or commercial plan (community <> professional).Keynote
Interesting behavior that I was able to reproduce with the basic Menu control as well. You can't reliably switch between main menu headers when you hold down the Ctrl or Shift keys. I happen to agree with @Keynote and @Doreendorelia though, using a modifier key on a context menu doesn't seem like a normal way to interact with your UI.Changeover
Microsoft Windows uses modifiers for its desktop popup and several mainstream 2D/3D graphics applications also do.Oilskin
C
2

MenuItem sets an internal flag when a key is pressed that stops mouse events from being registered temporarily, regardless of if it is actually a key that performs navigation. This reflects the behavior that I see, which is that the selection stutters when I hold down any key, not only modifiers. https://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/windows/Controls/MenuItem.cs,2049

Since it's private there is no proper way to fix this. However if it is critical you can add a KeyDown handler for all your MenuItems and then change it with reflection

var menu = sender as MenuItem;
if (menu != null)
{
    var parent = ItemsControl.ItemsControlFromItemContainer(menu);
    MethodInfo setBoolField = menu.GetType().GetMethod("SetBoolField",
        BindingFlags.NonPublic | BindingFlags.Static);
    setBoolField.Invoke(this, new object[] { parent, 0x04, false });
}

If you want you can first check if the key was a navigation key to retain the desired behavior.

I would personally consider this a bug in WPF.

Circumspect answered 4/10, 2020 at 18:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.