Prev: reply
Next: Formsauthentication timeout and 2 login pages
From: fred06250 on 29 Jun 2010 09:46
Hello All

I ve got 2 ContextMenuStrip

menu1 :
_A
_B

menu2 :
_C
_D

I set Opening on both menu
menu1.Opening += new CancelEventHandler(MyOpening1);
menu2.Opening += new CancelEventHandler(MyOpening2);

now I want to merge these 2 menus into one :

ContextMenuStrip newMenu= new ContextMenuStrip();
ToolStripManager.Merge(menu1, newMenu);
ToolStripManager.Merge(menu2, newMenu);

newMenu.Opening += new CancelEventHandler(myNewOpening);

In fact I m stuck here :
when the newMenu is about to be displayed, OnOpening is fired but how
can I call the Opening of the other two menus (menu1 & menu2) ??

thanks in advance

fred


From: Peter Duniho on 29 Jun 2010 10:58
fred06250 wrote:
> Hello All
>
> I ve got 2 ContextMenuStrip
>
> menu1 :
> _A
> _B
>
> menu2 :
> _C
> _D
>
> I set Opening on both menu
> menu1.Opening += new CancelEventHandler(MyOpening1);
> menu2.Opening += new CancelEventHandler(MyOpening2);
>
> now I want to merge these 2 menus into one :
>
> ContextMenuStrip newMenu= new ContextMenuStrip();
> ToolStripManager.Merge(menu1, newMenu);
> ToolStripManager.Merge(menu2, newMenu);
>
> newMenu.Opening += new CancelEventHandler(myNewOpening);
>
> In fact I m stuck here :
> when the newMenu is about to be displayed, OnOpening is fired but how
> can I call the Opening of the other two menus (menu1 & menu2) ??

If you don't have control over the subscription on the other menus, you
have no way to get the event handlers for their events. If you do, then
of course you can just take advantage of the knowledge of what methods
were used and use them in your own code.

If you do have control over the creation, initialization, and use of the
original menus then one approach to the latter is to sub-class the
ContextMenuStrip class and provide subscribe/unsubscribe methods for the
other code to use for the Opening event, so that your sub-class has
access to the handlers as they are added and removed. Of course, this
only works if you can ensure that the code subscribing or unsubscribing
to or from the event calls your methods rather than accessing the event
directly.

Then maintain a private delegate field that matches the subscription
state that you can query later (via a property or method).

(You could create a whole new event in the sub-class, and provide an
explicit add/remove accessor implementation, but IMHO because of the
inability to actually override the base event, this could actually be a
little more confusing, maintenance-wise).

Another alternative to the above would be to provide a kind of proxy
class that the "MyOpening1" and "MyOpening2" handlers are subscribed to
instead of the menus themselves, and in which you also provide features
for maintaining and retrieving the subscription state. This is not much
different from writing a sub-class, but it encapsulates the subscription
management in a non-control class, which you may or may not find to be a
simpler way to do it.

In general, the state of event subscription is private to the class
implementing the event. Unless the class provides an exception to this
(and most don't, including ContextMenuStrip), you can't get the event
subscription state after the fact. The best you can do is intercept it
somehow as you are add/removing handlers.

Pete
 | 
Pages: 1
Prev: reply
Next: Formsauthentication timeout and 2 login pages