I understand the benefits of events using delegate types with signature delegate void delegate_name(object sender, EventArgs e)
a) But besides the fact that it may save us some typing, are there any other reasons why we should use already defined delegate types EventHandler/EventHandler<T>
instead of declaring our own delegate types with signature delegate void delegate_name(object sender, EventArgs e)
?
b) Two other reason I can think of for using the predefined delegate types EventArgs/EventArgs<T>
are:
people consuming particular event ( say event EventHandler my_event
) will immediately know how to use that event?
perhaps some popular third party methods accept as parameters EventHandler/ EventHandler<T>
delegate types, and thus if there’s any chance that our code may use those third party methods, we should use predefined delegates EventHandler/Eventhandler<T>
?
thank you
The advantage of using EventHandler<TEventArgs> is that you do not need to code your own custom delegate if your event generates event data. You simply provide the type of the event data object as the generic parameter.
Events Have Private Invocation Events are typically public class members. By comparison, delegates are often passed as parameters and stored as private class members, if they are stored at all.
A delegate is a way of telling C# which method to call when an event is triggered. For example, if you click a Button on a form, the program would call a specific method. It is this pointer that is a delegate. Delegates are good, as you can notify several methods that an event has occurred, if you wish so.
Use the EventHandler<TEventArgs> delegate for events that include data about the event. These delegates have no return type value and take two parameters (an object for the source of the event and an object for event data).
To me, the question is a little strange. What would be the benefit of doing this otherwise (defining delegate types that exactly match EventHandler<TEventArgs>
for some TEventArgs
)?
That said, there is at least one benefit I can think of to doing it the "normal" way: certain APIs already expect to deal with EventHandler<TEventArgs>
delegates; for example, Rx Extensions includes a method that looks like this:
Observable.FromEvent<TEventArgs>(
Action<EventHandler<TEventArgs>> addHandler,
Action<EventHandler<TEventArgs>> removeHandler
);
If you defined your own delegate, using methods like this -- which expect EventHandler<TEventArgs>
delegates -- would become more complicated than necessary for no added benefit (that I can see, anyway).
You forgot an important one:
You've answered your own question:
EventHandler
type let's you easily integrate events from other librariesIn short; there's no good reason not to use it unless you're forced to (which typically is the result of people not being aware of it, or not understanding it).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With