is there - in windows forms - a way to enumerate the eventhandlers
attached to a certain controls event?
E.g. can i check somehow, if the is already a method bound
to button1.Click, and which method it is?
In Java there used to be a listeners collection you could
enumerate and also cleanup if you want to remove all attached
handlers. I do not know of such a thing in .NET...
There is and there isn't. It just depends on the class.
Java's event model is completely explicit -- there's no language or
framework support for it at all -- and they chose to provide for, in
_some_ cases, a method to return an array of listeners for a given event.
E.g. Component.getComponentListeners() (note that not all classes do this
for all events).
In C#, the event really has two parts. The public API and the private
one. The public API is simply two methods: add and remove. The private
API is whatever you want, but by default it's simply a delegate field that
stores the subscribers to the event. When you use the default
implementation of an event, you see this in the sense that code outside
the declaring class can only add or remove subscribers to the event, but
code inside the declaring class sees an actual delegate field that can be
assigned, inspected, etc. in addition to the usual add/remove operations
possible on a delegate type.
Even if a class provides an explicit implementation of an event (as the
Forms controls do for their events), unless that class was specifically
designed to expose the list of subscribers, you have no way to get at it.
It's a private implementation detail of the class. And the Forms classes
are like that.
For events you declare, you can of course provide that kind of API.
However, my experience has been that in reality it's better to find a
different way to accomplish your goals. It can be a maintenance headache
for some code outside the subscribing code to remove a subscriber at will;
it's much better to provide some kind of cooperative API to have
subscribers remove themselves, or even to not try to force unsubscription
at all.
Without knowing your specific goal, it's hard to offer specific advice.
But the bottom line is that you can only do what you want for classes
where you have control over the declaration and implementation of the
event, and even in those cases there's probably a better way to accomplish
the ultimate goal than by exposing the list of subscribers to the event.
(All of the above ignores, of course, solutions involving reflection...you
can do practically anything you want if you're willing to use reflection,
but reflection is almost always the wrong way to solve a problem).
Pete
