tags:

views:

157

answers:

5

Possible Duplicate:
What is the difference between a delegate and events?

Possible Duplicate:
Difference between events and delegates and its respective applications

(copied from this duplicate)

When i have to raise an event i do this

public delegate void LogUserActivity(Guid orderGUID);
public event LogUserActivity ActivityLog;

even this works

public delegate void LogUserActivity(Guid orderGUID);
public LogUserActivity ActivityLog;

What is the difference between two of them

+1  A: 

An event is an abstraction over a delegate, just as a property is an abstraction over a field. And - just like a property - an event allows you to gain fine control over what happens when a handler is added/removed:

public event LogUserActivity ActivityLog
{
    add { ... }
    remove { ... }
}

Indeed, your event may not have a delegate backing it at all, just like a property may not necessarily have a field backing it.

HTH, Kent

Kent Boogaart
+3  A: 

There are three things here:

  • Declaring a delegate type
  • Creating a public variable of a delegate type
  • Creating a public event of a delegate type

The variable is just a normal variable - anyone can read from it, assign to it etc. An event only exposes subscribe/unsubscribe abilities to the outside world. A field-like event as you've shown here effectively has a "default" subscribe/unsubscribe behaviour, stored in a field with the same name. Within the declaring class, you access the field; outside you access the event.

I have an article about events and delegates which explains in more detail.

EDIT: To answer the comment, you can easily initialize a field-like event with a "no-op" handler:

public event LogUserActivity ActivityLog = delegate{};
Jon Skeet
jon--when i need to call ActivityLog(),i first check whether it is null or not.Is there any way of assigning default to ActivityLog,so that it is never null.
Rohit
@Rohit: Edited to answer the comment.
Jon Skeet
+1  A: 

Events and public delegates differ in one big way that keeps me from using public delegates in most cases:

Event: obj.ActivityLog = null; // invalid

Public Delegate: obj.ActivityLog = null; // valid

This matters, because I only want the subscriber to add/remove themselves from the list in most cases. I don't want other objects unhooking events from other subscribers.

In cases where the delegate is less of an event and more of a callback, I tend to use public methods to do this and keep the public delegate from being exposed directly:

obj.RegisterActivityCallback(...)

Brian Genisio
A: 

In the first case you can assign multiple listeners to your ActivityLog event as in:

logger.ActivityLog += new LogUserActivity(Listener1);
logger.ActivityLog += new LogUserActivity(Listener2);

Both methods (Listener1 and Listener2) will be called when the event is fired. In the second case you are not creating an event but a delegate. In this case you can only assign one listener:

logger.ActivityLog = new LogUserActivity(Listener1);

In this case you do not fire an event but instead you call the delegate. An event is really just a chain of delegates that are called in turn.

Jakob Christensen
A: 

to add to all the previous answers, An event IS a delegate, of a specific type. A delegate is a type that is designed to act as a "smart" function pointer, or, putting it another way, as a smart "wrapper" for a function pointer, that allows the compiler to intelligently decide at compile time whether the function(s) you are sticking into the delegate are consistent with the uses you are making of the delegate (consistency is based on the function signature).

An event is a delegate with a specific signature, specifically, one that does not return anything (returns void), and takes two parameters, a System.object, to hold a reference to whatever object triggered the event, and an instance of some type derived from System.EventArgs, to hold whatever other data the event needs to carry with it from the initialtor to the handler.

Charles Bretana