Events, delegates, callbacks and methods

  • Thread starter Thread starter Michael McDowell
  • Start date Start date
M

Michael McDowell

I'm confused:

"why do we need to assign a method to a delegate then assign the delegate to
an event why not just assign the method to the events event handler"

and

"how does making a callback to some method differ from calling the method as
per normal"?

If anyone's got a minute or two to explain this stuff to me I'd be really
appreciative (even a pointer to an online paper would do).

Confused,
Michael
 
Hi,

you do not have to assign a delegate an event. You create events of some
delegate type.

You declare delegates (just a special class implicitly inherited from
Delegate, or MulticastDelegate) to specify how the methods assigned to this
delegate should look like (also called a signature). They also contain a
list and some other stuff to hold the references to the methods assigned to
them, so they can fire them at some later point in time.
So you are actually subclassing Delegate or MulticastDelegate when you are
declaring a delegate (a little bit compiler magic here).
You can instantiate delegates like any other type, assign your methods to
it, fire them and so on.

Now, when you declare an event (of some delegate type), you are just
creating a delegate of that type, so it can hold references to methods (with
the same signature). It only looks different. The reason why you need to
add the 'event' keyword is to let the compiler know it is an event, so it
shows up in the property inspector (in case of a component). The compiler
also generates two hidden methods to add and remove methods to the event (or
delegate if you like). That's why you can use the += and -= syntax.
The compiler will also add a hidden delegate instance which will actually
hold the references assigned to the event. Again compiler magic.

So, an event is more or less the same as a delegate instance, with some
hidden extras to make it visible to the designer and to make it easier to
use (+= and -=).

Hope this helped a bit,

Bram.
 
Hi,

forgot about the callbacks,

Callbacks are used when you need someone else to call a method (the callback
function or method) for you.
A good example is the Thread class. A thread needs a method to execute. It
has to do something, right ?
This method is passed to the Thread constructor by means of a delegate,
pointing to the method to run.
We usually don't call it a callback, it's more a thread function or thread
method, but you could look at it as a callback function.

Another example is the IComparer interface. When you sort an array
(Array.Sort), you can specify an interface to be used to compare the array
elements while sorting. So Array.Sort calls the Compare method of the
IComparer interface. Also some kind of a callback situation; it get backs
to you to do the actual comparison.

That's how the name 'callback' was *invented*. You just give some other
piece of code a method to get back to you while it's doing its thing, to get
some information from you, or to have you do something yourself, or
whatever...

hope you're a little bit less confused now,

Bram.
 
Michael said:
"why do we need to assign a method to a delegate then assign the
delegate to an event why not just assign the method to the events
event handler"
Click to expand...

The method called by the delegate is usually protected from outside sources.
Delegates solve the accessibility problem quite nicely.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
Michael,
"why do we need to assign a method to a delegate then assign the delegate to
an event why not just assign the method to the events event handler"
Click to expand...

Do you mean why we have to type

obj.SomeEvent += new DelegateType(Handler);

rathern than simply

obj.SomeEvent += Handler;

? If so, I believe you'll be able to use the latter syntax in the
Whidbey release of C#.



Mattias
 
? If so, I believe you'll be able to use the latter syntax in the
Whidbey release of C#.
Click to expand...

When's Whidbey out*, anyway? And is Whidbey the code-name for 2.0?

* i.e.: available for use in an IDE
 
When's Whidbey out*, anyway?
Click to expand...

Don't know, but if marketing decides, probably six months before it's
actually ready. :-)

And is Whidbey the code-name for 2.0?
Click to expand...

Yes, v2.0 of the framework and v8.0 (or 200?) of the VS IDE.



Mattias
 
Back
Top