Coding Practice Question - Usage of System.EventArgs

[Frankie]

The .NET Framework provides us with built-in event handlers:
System.EventHandler
and the generic
System.EventArgs<TEventArgs>

It appears that those built-in event handler delegates are just a
convenience for us, as we can use those instead of creating a new delegate
for every event that we implement.

Question: Is it good to use those built-in event handlers as a matter of
course - and not create a new delegate for our events - provided that the
standard event handler signature [object sender, EventArgs e] will suffice?

Is there any advantage to creating a new delegate _even when_ the built-in
ones listed above would suffice?

Thanks.

 

[Nicholas Paldino [.NET/C# MVP]]

Frankie,

I don't see any. There really isn't a difference between a delegate
signature of:

delegate void MyEventHandler(object sender, MyEventArgs args);

And using EventHandler<MyEventArgs>. They will do the same thing, and
there isn't any real difference between them.

 

[Alberto Poblacion]

The .NET Framework provides us with built-in event handlers:
System.EventHandler
and the generic
System.EventArgs<TEventArgs>

It appears that those built-in event handler delegates are just a
convenience for us, as we can use those instead of creating a new delegate
for every event that we implement.

Question: Is it good to use those built-in event handlers as a matter of
course - and not create a new delegate for our events - provided that the
standard event handler signature [object sender, EventArgs e] will
suffice?

Is there any advantage to creating a new delegate _even when_ the built-in
ones listed above would suffice?

In all the code I've seen, the standard practice is to use
System.EventArgs whenever it is sufficient, that is when you do not need to
pass any additional data inside the argument.

The only advantage that I can think for using a different type of
delegate is that it would leave room for future expansion, meaning that you
could write lots of code using YourEventArgs and if you needed to modify the
event in the future to include an e.something in your event arguments you
would not need to modify all the existing code (except those parts that
needed to make some use of the new fields). But I haven't seen any code that
follows this practice, so I guess that it is not frequent at all to find
yourself in this situation (having to add some data to existing eventargs).

 

[Guest]

I think the primary reason for EventHandler is that the signature is so
common throughout the .NET Framework that it makes sense to have a predefined
one. With EventArgs (which is not really an "event handler", but a separate
class) this provides the base class from which all more complex EventArgs
functionality is derived, even though in many cases it serves no purpose ,
e.g., "EventArgs.Empty"
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Frankie]

RE: << EventArgs (which is not really an "event handler>>

geeze! I meant to put System.EventHandler in the subject of the OP..... not
EventArgs... hopefully the actual question I posed there made it clear what
I was inquiring about....

I think the primary reason for EventHandler is that the signature is so
common throughout the .NET Framework that it makes sense to have a
predefined
one. With EventArgs (which is not really an "event handler", but a
separate
class) this provides the base class from which all more complex EventArgs
functionality is derived, even though in many cases it serves no purpose ,
e.g., "EventArgs.Empty"
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

The .NET Framework provides us with built-in event handlers:
System.EventHandler
and the generic
System.EventArgs<TEventArgs>

It appears that those built-in event handler delegates are just a
convenience for us, as we can use those instead of creating a new
delegate
for every event that we implement.

Question: Is it good to use those built-in event handlers as a matter of
course - and not create a new delegate for our events - provided that the
standard event handler signature [object sender, EventArgs e] will
suffice?

Is there any advantage to creating a new delegate _even when_ the
built-in
ones listed above would suffice?

Thanks.