Question about Events and delegates

  • Thread starter Thread starter Flare
  • Start date Start date
F

Flare

Hi i have a qusstion about events and delegates. Especially the precis role
of the Event.

Eg. We have a class wich want to fire events so we declare:

public delegate void TestEventHandler(object sender, EventArgs arg);
public event TestEventHandler Test;

And fire the event with

if(Test != null)
Test(this, new EventArg());

Is the right:
Test is actually a MultiCast delgate? Debugger says it is! OK.

Buth then why use the event keyword in front of the Test and insted not
just:

public delegate void TestEventHandler(object sender, EventArgs arg);
public TestEventHandler Test;

And fire the event with
if(Test != null)
Test(this, new EventArg());

It work fine. Why do we need the event keyword? Clearly there is a reason.
Someone who can tell me?

reagards
Anders
 
Flare said:
Hi i have a qusstion about events and delegates. Especially the precis
role
of the Event.

Eg. We have a class wich want to fire events so we declare:

public delegate void TestEventHandler(object sender, EventArgs arg);
public event TestEventHandler Test;

And fire the event with

if(Test != null)
Test(this, new EventArg());

Is the right:
Test is actually a MultiCast delgate? Debugger says it is! OK.

Buth then why use the event keyword in front of the Test and insted not
just:

public delegate void TestEventHandler(object sender, EventArgs arg);
public TestEventHandler Test;

And fire the event with
if(Test != null)
Test(this, new EventArg());

It work fine. Why do we need the event keyword? Clearly there is a reason.
Someone who can tell me?

The event keyword creates an event property(literally, event results in two
methods, add_EventName and remove_EventName, which are used to add and
remove listener delegates. The spec also defines a protected raise_EvetnName
accessor, but C# nor VB uses it to my knowledge, C++ does I think).
Basically it hides the delegate from outsiders. It restricts raising the
event to your local class and keeps others from modifying(or accessing) the
delegate list, that combined with the += and -= C# syntax and metadata
declaring the member is an event, not just a delegate are the primary
reasons. Imagine the fun if external code could wipe out all listeners or
fake events being raised.

I'd never recommend using direct delegate fields.
 
I'd never recommend using direct delegate fields.

Ok. So. Event dosent provide "extra functionality" except the delagate
hideing (good point). Right?

About the add and remove wich you say isnt implemented in C#...isnt it used
in the overloaded syntax += on the delegate?

Actually thougt that the event had more "logic".

Anders
 
Flare said:
Ok. So. Event dosent provide "extra functionality" except the delagate
hideing (good point). Right?

About the add and remove wich you say isnt implemented in C#...isnt it
used
in the overloaded syntax += on the delegate?
Well, += and -= for C# and events is a bit of syntactic sugar to the add and
remove accessors.
 
Back
Top