Say, you have a .NET 2.0 Windows Forms application with one form and on the form one menu strip at the top, you know, very simple. On that menu strip, you have the menu 'Foo' and on that menu you have a menu item 'Bar', which are in .NET 2.0 of type ToolStripMenuItem. You assign a keyboard shortcut to the Bar menu item, say Cntrl+B.
You disable the menu 'Foo', by setting its Enabled property to false. Now it's impossible for the user to click / select the Bar menu item, right?
Well, any decent developer would think so indeed. However, when you press Cntrl-B, the 'Bar' menu item is still selected .
In .NET 1.x, when you pressed the shortcut keys for a menu item on a disabled menu, you'd get what you'd expect: nothing. Though in .NET 2.0 that's not the case anymore. I'm not sure if this is a bug or not, I'm sure some MS employee will come up with 'by design' and some reasoning behind it, but IMHO this is a pretty bad issue, simply because it creates a lot of problems in applications which have context-sensitive menu items, e.g. you disable a couple of menu items on a menu when they're not available and when the whole menu isn't available, you simply disable the whole menu. Now that's not possible anymore: the whole menu tree has to be disabled when the menu is disabled.
As a 'fix' for this either requires me to add a myriad of check routines if the parent menu is enabled/disabled to all kinds of menu handlers, or wait till eventually MS fixes it in a future service pack, does anyone know a workaround for this which doesn't require me to add code which disables/enables hierarchies of menu items to overcome this bug?
Update: Jfo posted a workaround for this problem. Great!