about event handlers

Tony

Hello!

Is it the normal procedure in C# and .NET framework to always use the actual
event object which is
passed as the second parameters to the event handler.

All of them are derived from the base class which is EventArgs so because of
this the second parameters could in all cases be EventArgs which had be be
cased
in the most cases to the the actual referenced event argument object before
accessing the referenced object.

Here I have some examples
private void textBoxAge_KeyPress(object sender, KeyPressEventArgs e)
private void textBoxAge_Validating(object sender, CancelEventArgs e)
private void textBox_TextChanged(object sender, EventArgs e)

//Tony

Jun 27 '08 #1

Peter Duniho

On Tue, 24 Jun 2008 23:51:03 -0700, Tony <jo*****************@telia.com>
wrote:

Is it the normal procedure in C# and .NET framework to always use the
actual
event object which is
passed as the second parameters to the event handler.

All of them are derived from the base class which is EventArgs so
because of
this the second parameters could in all cases be EventArgs which had be
be
cased
in the most cases to the the actual referenced event argument object
before
accessing the referenced object.

Typos notwithstanding, you've answered your own question. :)

Most of the time, you want the data that's in that EventArgs sub-class.
It wouldn't make any sense to declare your event handler method to take
EventArgs instead, only to have to cast it before you use it.

So, yes...I feel it's "the normal procedure" to always use the actual
type, rather than the base type.

I suppose that for an event handler where you're going to ignore that
parameter, you could declare the argument as just the base class. In
fact, that might help document the fact that the handler method is
ignoring the parameter. But in that scenario, you might want to ask
yourself why it is you're handling the event in the first place. :)
(That's for events that actually do sub-class the EventArgs; obviously for
events that don't, you'd use EventArgs and that'd be perfectly normal).

Pete

Jun 27 '08 #2

Tony

Hello!

One more thing assume I create an event and an object derived from the
eventArgs containing some info about the
event.
Then create another event also with an object derived from the eventArgs
containing some info about the
event.

When creating the event handler I have two choices either use EventArgs as
the second parametr and cast to the actual type
or
use two separate event handler with the actual type as the second paramer.

So does it exist some recommended guidline to which one to use.
I would say use different event handler unles they they are logically
connected in some way.

Give me some comment about which one to use according to OOP.

//Tony

"Peter Duniho" <Np*********@nnowslpianmk.comskrev i meddelandet
news:op***************@petes-computer.local...

On Tue, 24 Jun 2008 23:51:03 -0700, Tony <jo*****************@telia.com>
wrote:

Is it the normal procedure in C# and .NET framework to always use the
actual
event object which is
passed as the second parameters to the event handler.

All of them are derived from the base class which is EventArgs so
because of
this the second parameters could in all cases be EventArgs which had be
be
cased
in the most cases to the the actual referenced event argument object
before
accessing the referenced object.

Typos notwithstanding, you've answered your own question. :)

Most of the time, you want the data that's in that EventArgs sub-class.
It wouldn't make any sense to declare your event handler method to take
EventArgs instead, only to have to cast it before you use it.

So, yes...I feel it's "the normal procedure" to always use the actual
type, rather than the base type.

I suppose that for an event handler where you're going to ignore that
parameter, you could declare the argument as just the base class. In
fact, that might help document the fact that the handler method is
ignoring the parameter. But in that scenario, you might want to ask
yourself why it is you're handling the event in the first place. :)
(That's for events that actually do sub-class the EventArgs; obviously for
events that don't, you'd use EventArgs and that'd be perfectly normal).

Pete

Jun 27 '08 #3

Peter Duniho

On Wed, 25 Jun 2008 00:34:36 -0700, Tony <jo*****************@telia.com>
wrote:

One more thing assume I create an event and an object derived from the
eventArgs containing some info about the event.
Then create another event also with an object derived from the eventArgs
containing some info about the event.

When creating the event handler I have two choices either use EventArgs
as
the second parametr and cast to the actual type or
use two separate event handler with the actual type as the second
paramer.

If the processing of the event is so similar as to justify using the same
handler method for both, then the event should almost certainly be using
the same EventArgs sub-class.

So does it exist some recommended guidline to which one to use.
I would say use different event handler unles they they are logically
connected in some way.

Yes, I try not to reuse the same method for operations that are _not_
logically connected in some way. :)

(In fact, as I've noted many times before in this newsgroup, I don't even
like having one method doing two disparate things even if those two things
do in fact happen to be related to each other in some logical way...see my
repeated objections to MSDN's approach to methods using Invoke() and
InvokeRequired, for example).

Pete

Jun 27 '08 #4