If you do not 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 do not, including ContextMenuStrip), you cannot get the event
subscription state after the fact. The best you can do is intercept it
somehow as you are add/removing handlers.
Pete