[2.0] Why do I need delegates for events?

[JPicasso]

Bear with me, I'm a VB6 programmer with some vb.net exp. Most of my grief is coming from the syntax.

So in every example on how to handle events in C#, the authors begin with defining a Delegate. Why? I do not, apparently need a delegate to handle the Event... or at least I don't need to explicitly declare one. I can use the EventHAndler from System.EventHandler, right?

My code for the event only consists of four main pieces,
1. Declare the Event
2. Call (or raise) the event
3. Assign the handler for the event (+=)
4. method that runs in response to event.

What am I missing?

[sunburnt]

If you create your own delegate, you can create events with different arguments than what is provided by the System.EventHandler.

For example, if I had an event that would be raised when an array of bytes was ready, and included a string description of what was in the bytes, I could do something like this:

public delegate void OnBytesReady(object sender, byte[] data, string desc);
public event OnBytesReady BytesReady;

// ...
        void foo()
        {
            if (BytesReady != null)
                BytesReady(this, new byte[]{1, 2, 3}, "the numbers 1-3");
        }

[JPicasso]

Hmmm... yes...

It appears that I will need that functionality too. Since what I'm doing is exactly that.... fire an event when a new dataset is ready and load that puppy up.

Still, for starting examples, it would be nice to just show some code that used the simple "EventHandler" so Dumb@$$es like me could assimilate the syntax, then add in that high-falootin fancy argument stuff later.

Thanks!

[wossname]

You fail to realise that VB6 is a sack of crap and should not be used as a benchmark by which other languages are measured.

The thing about the OOP approach to events is that you can add and remove event handlers at runtime in response to various states your program hapens to fall into.

Yes the syntax is a real ball-ache and its about as intuitive as a not very intuitive thing, but it is powerful and it just takes a bit of patience and a read-through of the documentation a few times before it finaly clicks.

When it finally does click you'll realise that it is better than the old, stupid way of handling events and you'll like it.

[wossname]

MSDN has a good example of this anyway. I'm surprised that wasn't the first place you looked.

[JPicasso]

I've not had much luck with MSDN and the C# stuff. This time was no different.

[JPicasso]

Well, now, technically, I don't need an "official" delegate.

I can cram whatever (class, derived from :EventArgs) I want into the EventArgs argument and then
re-cast the "e" as whatever (class) I put in.
Then I can access the props and methods that I need.

It certainly seems like declaring what you're actually doing would be better from a coding practices stance, because this way, the reciever needs to know how to handle the EventArgs data.


...but it appears I don't NEED a delegate.

[wossname]

Well in theory you don't need to use a compiled language, you could just use QBasic for everything. But that would be stupid.

[sunburnt]

Well, now, technically, I don't need an "official" delegate.

I can cram whatever (class, derived from :EventArgs) I want into the EventArgs argument and then
re-cast the "e" as whatever (class) I put in.
Then I can access the props and methods that I need.

It certainly seems like declaring what you're actually doing would be better from a coding practices stance, because this way, the reciever needs to know how to handle the EventArgs data.


...but it appears I don't NEED a delegate.

No, but what you've described is a hack. Imagine if all the events that could be raised by a form, for example, passed in an EventArg that had to be cast to something else. It would drive you crazy looking through the documentation, trying to find what you should be casting the argument to. It's much simpler to implement a delegate that describes exactly what is being passed to your function.