If I create a menu with two items (say \"Item1\" and \"Item2\" and then create two subitems under each one (1A, 1B, 2A and 2B), and then disable Item1, I\'d expect that 1A and 1
I've faced the same problem and would like to add a few words to the answer. You would probably want to implement workaroud mentioned by Chris Taylor in a separate control inherited from menu item, and make a unit test. In this case you would need to use Available property instead of Visible. Here is the quote from the http://blog.excastle.com/2008/12/28/fixing-menustrip-part-2-visible-vs-available-and-a-repro-case/
ToolStripMenuItem has two visibility properties: Visible and Available. They both do the same thing, except when they don’t.
To be more specific, both their setters do the same thing. So if you want to hide a menu item, you can either set Visible to false, or you can set Available to false. Same thing. So why are there two properties for the same thing?
The difference is if you ever want to read the properties, to find out whether the item is already hidden. The Visible getter does not do what you want. Never use it. Reading Visible does not tell you “did I set Visible to true?” No, that’s what Available is for. (Obviously.) No, reading Visible tells you “is the menu currently popped up on the screen?” Which has a usefulness score of somewhere less than or equal to toe fungus.
Summary: always use Available. Never use Visible. The one exception is the form designer — Available isn’t shown in the Property Grid, so there you’re stuck with Visible.
Regards,
Max
I can confirm that this occurs with the MenuStrip for Framework 2.0, 3.5 and 4.0. The only reasonable workaround that I have is to set the Visible
property to false
, so the item does not appear at all. Not Ideal, but better than having the sub-items accessible.
Of course you can also create a function that will recursively disable all child items, that way even if they appear, they are at least disabled, you will need to maintain the previous state to ensure that you do not later re-enable a child item that is actually inteded to be disabled etc. The documentation indicates that this is actually what happens, but that is not the case, sub-items remain enabled even when the parent item is disabled.