Hi

Can anyone tell me the practical difference between events and delegates, I have used events in my programs, but not delegates, it seems almost same to me.

Thanx

Regards
Mike

Fortune favours the brave, so don't regret on missed oppurtunities.

__________________
Regards
Mike

I just like to think of "events" as a design pattern, one in which one object uses a delegate object to invoke methods on other objects. The standard .NET event model seems to want to refine that definition a bit futher by suggesting that the delegate used should have a specific signature, i.e., one that takes both an object representing the source of the event and an object derived from System.EventArgs representing data associated with the event. But delegates, per se, can have any signature whatever, and invoke any kind of method whatever (not simply "event handlers"). They are just objects that wrap (or point to) methods.

Been working with Rockford Lhotka's CSLA stuff for a while, and tried to carve out some code where he uses delegates in a business object data validation role. Haven't pulled it off yet, but ran into someone who achieved something similar based on CSLA at:

http://www.codeproject.com/csharp/De...essObjects.asp

Have a look at how the SimpleRuleDelegate functions.

Also benefitted from both of Jeff Richter's MSDN articles on the topic at:

http://msdn.microsoft.com/msdnmag/is...t/default.aspx

and

http://msdn.microsoft.com/msdnmag/issues/01/06/net/

HTH,

Bob

Of course, an event is also a type member defined by using the 'event' keyword. But you can implement an "event pattern" without defining an event member in the publishing object. Just use a plain old delegate. (I guess it would be fair to say that the .NET event model is Microsoft's implementation of the Observer pattern using delegates). Don't know who the author of the following is, but here's a version of a publisher/subscriber style observer pattern using just a delegate (no event member):

class Program {
    static void Main(){
        Interesting i = new Interesting();
        Curious c = new Curious(i);
        i.Wiggle();
    }
}

public class Interesting {
    public delegate void ChangeHandler();
    public ChangeHandler Change;
    public void Wiggle() {
        if (Change != null)
            Change();
    }
}

public class Curious {
    public Curious(Interesting i) {
        i.Change += new Interesting.ChangeHandler(React);
    }
    public void React() {
        System.Diagnostics.Debug.Write("Something happened!");
    }
}

A Curious object registers its React method with an Interesting object, then waits for the Interesting object to Wiggle.

The advantage of defining an event member in an object's interface is that, by doing so, the object is explicitly exposing (via Intellisense, reflection, etc.) its capability to publish notifications and allow other objects to register and unregister interest in it. But internally, a delegate maintains the set of registered objects, and notifies those objects when something interesting happens.

HTH,

Bob