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).

Jelly Ama
  • 6,701
  • 3
  • 20
  • 23
  • 1
    Context menus are provided by Windows, not WPF. I don't see any difference when Ctrl is pressed. – Panagiotis Kanavos Sep 23 '20 at 09:55
  • 1
    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. – Sinatr Sep 23 '20 at 10:14
  • 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. – Jelly Ama Sep 23 '20 at 10:36
  • _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). – Funk Sep 28 '20 at 15:04
  • 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 @Funk and @Sinatr though, using a modifier key on a context menu doesn't seem like a normal way to interact with your UI. – Peter Boone Sep 28 '20 at 15:32
  • Microsoft Windows uses modifiers for its desktop popup and several mainstream 2D/3D graphics applications also do. – Jelly Ama Sep 30 '20 at 09:16

1 Answers1

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.

Mim
  • 453
  • 4
  • 6