Some questions on Raising events

[Dom]

I'm teaching myself how to write a usercontrol, and how to raise
events within the control. Some questions came up. Let's say I the
event is called "Flyover", and everybody knows what is meant by
FlyoverEventArgs and OnFlyover.

1. When the event is to be raised, as I understand it, I do not raise
it directly. Instead I call a procedure "OnFlyover (new
FlyoverEventArgs (...))". Then I write the procedure called
"OnFlyover" which then does nothing but raise the event -- "Flyover
(this, e)". What is the purpose of "OnFlyover"? It seems to be
nothing but a link in the chain. It seems that instead of calling
this, I can just raise the event itself. Is it only to allow other
users to override it?

2. When I write FlyoverEventArgs, I always get an error about
accessibility, which can only be corrected if I make the class
"public". I thought "public" was the default for a class. Even the
IDE, when it creates a stub, does not insert the word "public".

3. Once, when I wrote FlyoverEventArgs, I forgot that it was supposed
to extend the class "EventArgs". But nothing went wrong. Why are you
told to extend "EventArgs"?

All things considered, it seems that the IDE should have a special
insert for "EventArgs" that includes the word "public" and the
extension of "EventArgs" automatically in the stub.

 

[Jon Skeet [C# MVP]]

I'm teaching myself how to write a usercontrol, and how to raise
events within the control. Some questions came up. Let's say I the
event is called "Flyover", and everybody knows what is meant by
FlyoverEventArgs and OnFlyover.

1. When the event is to be raised, as I understand it, I do not raise
it directly. Instead I call a procedure "OnFlyover (new
FlyoverEventArgs (...))". Then I write the procedure called
"OnFlyover" which then does nothing but raise the event -- "Flyover
(this, e)". What is the purpose of "OnFlyover"? It seems to be
nothing but a link in the chain. It seems that instead of calling
this, I can just raise the event itself. Is it only to allow other
users to override it?

It allows them to override it, or call it - and it also lets you
encapsulate any nullity checking, locking etc in one place.

2. When I write FlyoverEventArgs, I always get an error about
accessibility, which can only be corrected if I make the class
"public". I thought "public" was the default for a class. Even the
IDE, when it creates a stub, does not insert the word "public".

No - the default access modifier is always the most restricted it can
be in C# (with one exception when you change the access to half of a
property). This means that for outer class, the default access is
internal; for nested classes, the default access is private.

3. Once, when I wrote FlyoverEventArgs, I forgot that it was supposed
to extend the class "EventArgs". But nothing went wrong. Why are you
told to extend "EventArgs"?

In C# 1, there was very little benefit in deriving from EventArgs. In
C# 2 and 3, however, delegate parameter contravariance means that if I
have a method:

void Foo (object sender, EventArgs e)

I can use that as the action for your delegate type, even though it's
declared to pass in FlyoverEventArgs - but only if FlyoverEventArgs
derives from EventArgs.

(There's nothing specific about EventArgs here, by the way - the
contravariance applied to delegates is general.)

All things considered, it seems that the IDE should have a special
insert for "EventArgs" that includes the word "public" and the
extension of "EventArgs" automatically in the stub.

You may not want it to be public though - not all events are public.
Besides, it's pretty rare to need to create your own event argument
type - I don't see that there would be much benefit in changing the
IDE's behaviour for it.

 

[Peter Duniho]

[...]

What is the purpose of "OnFlyover"? It seems to be
nothing but a link in the chain. It seems that instead of calling
this, I can just raise the event itself. Is it only to allow other
users to override it?

It allows them to override it, or call it - and it also lets you
encapsulate any nullity checking, locking etc in one place.

And, correct me if I'm wrong (like I have to ask ), but...

The "event" being used in the handler isn't the same as the "event" used
publicly, right? That is, the "It allows them to...call it" is very
important in the case where you want the event to be "raiseable" by a
derived class, since the derived class wouldn't have access to the
actual event instance member.

Pete

 

[Jon Skeet [C# MVP]]

And, correct me if I'm wrong (like I have to ask ), but...

The "event" being used in the handler isn't the same as the "event" used
publicly, right? That is, the "It allows them to...call it" is very
important in the case where you want the event to be "raiseable" by a
derived class, since the derived class wouldn't have access to the
actual event instance member.

Exactly. The member referenced within the class is actually the
delegate field, not the event.