Winforms – Prevent ToolStripMenuItem context menu from closing on click

c#-4.0contextmenucontrolseventswinforms

I'm trying to have my context menu stay on screen even after I click one of its dropdown items (when the shift key is pressed, though I don't think that matters to the issue). You can see an example of the behavior in Windows XP when you click on Start > All Programs > Accessories > [now hit your shift key] and click on Windows Explorer… The menu stays up.

It's a C# app, using Winforms, development machine is Windows 7, production is either XP, Vista or 7.

The toolstripmenuitem doesn't seem to have a closing event; only a closed one. Those familiar with a closing event will know that you can set a cancel flag to prevent the control from closing.

Also, when I try a workaround of remaking it visible from within either its click event or its closed event, it doesn't work. Although that would have been a tolerable workaround in the immediate, it is not for production.

Any suggestions or related info greately appreciated.

Thank you

Best Solution

I was able to have a dynamically created submenu of my ContextMenu stay on screen upon being clicked by setting the AutoClose property of its Parent DropDown menu to "False" like this:

ParentMenu.DropDown.AutoClose = false;

where ParentMenu is a ToolStripMenuItem.

The use of the Closing event of the DropDown's Parent ToolStripDropDownMenu to acheive this by setting a "Cancel" flag was not a viable solution because it caused inconsistant showing/hiding behavior in either of its 2 levels of Parent menus as well as causing unexpected visual artifacts on screen that I could not get rid of when later being hidden through code. It also seemed to cause certain events of the dynamically created menu's Parents to no longer fire, such as its MouseEnter event.

An interesting find during this experience was that although Visual Studio 2010's intellisense lists a LostFocus event for a DropDown of a context menu item; when adding this event to dynamically created menus it does not get fired; this is apparently a known behavior as mentionned here:

Related Question