Reasoning behind the EventHandler(object, EventArgs) signature

[John B]

What is the reasoning for recommending that all events have the
signature EventHandler(object sender, EventArgs e).
Obviously I can create a custom delegate
delegate void FooHandler(string foo)
and event FooHandler FooHappened

What are the benefits of creating derived eventargs classes for each
event instead of creating the delegate which is much easier IMO.

Am I missing something?

Cheers
JB

 

[Bob Powell [MVP]]

I guess for the same reasons that any good architect will impose some
sort of order on any framework they design.

The signature reassures the developer that a certain behaviour is
expected and that the sender of the event and some kind of event
argument, either raw or derived, will be provided. A void return type is
also imposing order and suggesting that info will be passed back in the
event arguments.

Creating your own delegates is perfectly acceptable but, if you were
writing any sort of commercial software, the choice would be nonsense
because it wouldn't fit with the plan.

Systems that use reflection to discover the capabilities of a component,
and there are lots of them these days, are also aware of the signature
so things like databinding use these events in the data change
notification system.

You would be strongly advised not to break what doesn't need fixing.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Jon Skeet [C# MVP]]

What is the reasoning for recommending that all events have the
signature EventHandler(object sender, EventArgs e).
Obviously I can create a custom delegate
delegate void FooHandler(string foo)
and event FooHandler FooHappened

What are the benefits of creating derived eventargs classes for each
event instead of creating the delegate which is much easier IMO.

Am I missing something?

Well, prior to 2.0, you weren't. I often wondered the same thing -
it's not like you could use a less specific event handling delegate as
a more specific one. However, with 2.0 delegates can be covariant, so
it makes a lot more sense. I'm still not 100% convinced, but there's
more reason than there was before

Jon

 

[Laura T.]

This reasoning is from the .NET SLAR:

"
If we want to add some new information in the event callback we can do it
without breaking clients. For example, if we need to add information about
the location an assembly was loaded from we would simply add a new property
to the AssemblyLoadEventArgs class. If we did not have the EventArgs class
we would have to create a whole new Delegate and a new event of that type
with a different name. It would be really ugly. Encapsulating the event data
in a subclass of EventArgs makes this scenario very smooth.
"

I do agree, if you are making a class library or components for external
use. Having a common base class is good (see Exception) choice.
You can pass your derived (extended) class to relevant standard events if
needed, as they expect EventArgs derived class.
Another question are the standards, the common ways to do things. When all
events have EventArgs (and sender), something different can disturb.

 

[John B]

Thanks for the responses guys.
Excellent information and viewpoints.

Cheers
JB

 

[Brian Gideon]

Well, prior to 2.0, you weren't. I often wondered the same thing -
it's not like you could use a less specific event handling delegate as
a more specific one. However, with 2.0 delegates can becovariant, so
it makes a lot more sense. I'm still not 100% convinced, but there's
more reason than there was before

Jon

Jon,

Did you mean contravariant? EventHandler has a void return type so I
don't think that would be in play. The parameters would though,
right?

Why doesn't C# support covariant return types on virtual methods in
subclasses? I thought I read somewhere that a newer version of Java
does.

Brian

 

[Jon Skeet [C# MVP]]

Did you mean contravariant? EventHandler has a void return type so I
don't think that would be in play. The parameters would though,
right?

Yup. I'm a fool

Why doesn't C# support covariant return types on virtual methods in
subclasses? I thought I read somewhere that a newer version of Java
does.

I can't remember, to be honest. I know it was one of the possible side-
effects of putting generics in. I agree, it would be very nice.