Event parameter; “sender as Object”, or “sender as

Question

When I write public events for my business objects, I've adapted the habit of always passing the instance as "sender as Object", in addition to additional specific parameters. I just asked myself now why am I not specifying the class?

So for you with more experience; Do you ever pass the distinct class as sender in an event? And if so, what are your decision criteria for when this is ok/not ok?

Answer 1

It is good practice to use the object sender, EventArgs e signature, as the method can handle any events of that signature. For example, in a project using a charting control, there are several types of MouseOver events - from a DataSeries, from the Legend, from the whole Canvas.

That way, you can handle any source of the event, as at most times, the information is in the EventArgs.

Also, you don't have to cast the sender when passing it to the delegate, as any class instance is an object deep down.

Answer 2

As far as I see it you can either create delegates with the parameters you want and then create an event using that delegate and then you can call the event and pass the parameters in or you can use Custom Event Argument as shown here. As the other answer suggests. Keep it consistent.

Doesn't really answer your question about the decision criteria but hope it helps

Answer 3

There is a design guideline that specified that an event-handler should have two params: sender (an Object) and e (EventArgs or derived from that).

Answer 4

There no such restriction. It is just a guideline that is followed throughout BCL (Base Class Library) and other popular frameworks.

I would recommend you follow it to keep it consistent if it is going to be used by other developers or be released as a framework.

Answer 5

My current philosophy is to keep code practices as close to the standard Microsoft way as possible. You get two things from this:

• New developers can quickly understand your code
• You train existing developers how the rest of the framework works

Answer 6

There was a lot of discussion on a related question on StackOverflow some time ago. Here is that question: Event Signature in .NET -- Using a strong-typed sender

Eventually, it comes down to preference. In most cases, you'd like your event handlers to be bound to a particular type of class so making the sender an object and then casting back to the class in order to get access to its properties might not go down well with you [it doesn't go down well for me either].

Besides, with .NET 3+ and the introduction of delegate covariance and contravariance, it should not be a problem to use a strongly typed delegate. I must admit, I've used strongly typed event handlers more than once in my code.

Like I said earlier, it comes down to preference; Microsoft just issued a set of guidelines not rules...