Make MenuStrip and ContextMenuStrip look more Windows-native

[chylex]

• .NET Core Version: 3.0
• Have you experienced this same bug with .NET Framework?: Yes

With the removal of MainMenu and ContextMenu native wrappers in .NET Core 3.1, and no alternative for native controls, it'd be a good idea to make the replacement strip controls look and feel more native.

Including screenshots from Windows 10 and 7, and RenderMode set to ManagedRenderMode and System to point out differences.

Windows 10

Native	Strip (System)	Strip (Managed)

Windows 7

Native	Strip (System)	Strip (Managed)

Additional Information

The visual differences should be obvious, but there are a few usability differences as well:

• In RenderMode = System, the hover highlight over a menu item with subitems - after the subitem menu becomes visible - lingers
• In the native menu, clicking on a menu item when the window is unfocused immediately activates that item; MenuStrip requires a second click
• In the native menu, pressing left arrow key when the first menu item is highlighted brings out the "right-click on window title bar" menu as if it was another menu item:
• The native menu does not take up any space in Form.ClientHeight; when migrating to a MenuStrip, you will lose 20 pixels of height
• There is a positioning difference between the native and strip context menu when invoked by a dedicated context menu key instead of a mouse
• Possibly more, this is just what I noticed after a few minutes of testing

Test Project

The test project targets .NET Core 3.0, and opens 3 windows (native + the 2 strip variations).

WindowsFormsStripControlsCore.zip

[merriemcgaw]

I think we should break this up into a couple of sub-issues:

• Change the colors of the RenderMode = System to truly match system
• Fix the tab ordering of the menu to include the window menu (icon in top right of form)
• Ensure our positioning of ContextMenuStrip invoked by the keyboard button matches how Notepad does it
• Investigate the space taken by the MenuStrip in Form.ClientHeight

I'd prefer not to change the way we require the form to get focus before invoking the MenuStrip's command. I'm not 100% sure this scenario, but we believe we should make the form have focus before invoking commands in the form. Concern that doing so would raise a potential accessibility issue

If you find any more issues could you please file separate issues for them and link this one?

[chylex]

Would you like me to break up the current issue into sub-issues, or will you do that and I should only file new ones if I find further differences?

I'd prefer not to change the way we require the form to get focus before invoking the MenuStrip's command.

It's different from how this style of main menus work on Windows. Any app I've tried immediately opens the clicked main menu item even if the window is initially unfocused:

• Native WinAPI apps such as notepad or pre-UWP calculator
• WPF apps such as Visual Studio
• Electron apps such as Visual Studio Code
• Other apps with completely custom main menus such as Steam
• Haven't tested UWP (or rather I don't know what on earth can be considered a "main menu" in those; if it's hamburger menus, then those also trigger without requiring focus on the window)

[RussKie]

Would you like me to break up the current issue into sub-issues, or will you do that and I should only file new ones if I find further differences?

If you don't mind, please raise a separate issue for each. The more details you provide - the better.

Any app I've tried immediately opens the clicked main menu item even if the window is initially unfocused:

Please raise this issue as well. In it please explain how to repro, I can't seem to get an unfocused app with an open menu/contextmenu.

Thank you

[chylex]

I will try to file separate issues today or tomorrow with more details.

Please raise this issue as well. In it please explain how to repro, I can't seem to get an unfocused app with an open menu/contextmenu.

Not sure I follow.

The issue is that with MenuStrip in an unfocused window, opening a menu requires 2 clicks - one to focus the window and one to actually open the menu - while MainMenu and basically every app that has a main menu only requires 1 click over the unfocused window to open the menu.

Context menu works as expected with both ContextMenu and ContextMenuStrip, no issue there.

[chylex]

I haven't opeend an issue on ClientHeight yet. I suspected that StatusBar vs StatusStrip would have the same issue, but StatusBar still exists in 3.1 and wasn't mentioned in the removal PR. Any idea what's up with that?

[RussKie]

but StatusBar still exists in 3.1 and wasn't mentioned in the removal PR. Any idea what's up with that?

Thank you for pointing, it was obviously missed in the clean up (we had a tight deadline). It will be removed in the .NET 5.0 timeframe, we will need to consider whether we'll patch 3.1.

[xv]

Having native/OS theming on MenuStrip and ContextMenuStrip would be amazing.

I've been using the now-removed MainMenu for 10+ years just so I can have a unified and consistent UI, and I am now stuck with .NET 4.8 because of how hideous MenuStrip looks. It was ugly in 2007 and it's even more ugly today, especially with its XP-reminiscent drop shadow that you'll instantly notice on Windows 11, and the lack of dropdown fade in animation.

Call MainMenu obsolete or whatever you feel like, but frankly, going from MainMenu to MenuStrip is a visual downgrade -- a bad one.

Please Microsoft 🙏

[chylex]

Since there's been no updates on this, my solution has been to port the removed controls from .NET Core 3.0. I only ported what I needed, which was ContextMenu and only some of its features; it required reflection to access private fields, but it does work: https://github.com/chylex/TweetDuck/tree/master/windows/TweetLib.WinForms.Legacy

It should be possible to port MainMenu, other ContextMenu features, or anything else that was removed, you'll just have to maintain it yourself and thoroughly test it.

[modz2014]

nothing for windows 11 yet either