473,320 Members | 2,027 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Where is the delegate?

Ant
Hello,
Very simple question but one I need clarified.

Which part of the statement below is considered the 'delegate'?

Is it the 'new System.EventHandler'
or the
btnAccept_Click?
or is it the piece of code which doesn't appear here, but abstracts the
btnAccept_Click method?

this.btnAccept.Click += new System.EventHandler(this.btnAccept_Click);

Many thanks for any answers to this semingly silly question.
Ant
Mar 6 '06 #1
7 1758
"Ant" <An*@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...
Hello,
Very simple question but one I need clarified.

Which part of the statement below is considered the 'delegate'?

Is it the 'new System.EventHandler'
or the
btnAccept_Click?
or is it the piece of code which doesn't appear here, but abstracts the
btnAccept_Click method?

this.btnAccept.Click += new System.EventHandler(this.btnAccept_Click);


btnAccept_Click is the target for the delegate
and "new System.EventHandler" creates an instance of the System.EventHandler
delegate.
this.btnAccept.Click holds none, one or more instances of the
System.EventHandler delegate.

Michael
Mar 6 '06 #2

"Ant" <An*@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...
Hello,
Very simple question but one I need clarified.

Which part of the statement below is considered the 'delegate'?

Is it the 'new System.EventHandler'
or the
btnAccept_Click?
or is it the piece of code which doesn't appear here, but abstracts the
btnAccept_Click method?

this.btnAccept.Click += new System.EventHandler(this.btnAccept_Click);

Many thanks for any answers to this semingly silly question.


The delegate is Click.

The only difference between
"public event EventHandler Click;" and "public EventHandler Click;"
is the operations that you are allowed to perform on the delegate from
outside the class.
From inside the class they are indistinguishable other than by reflection.

Just to confuse you, although declared as delegate, the actual base type of
EventHandler and all other delegates is actually System.MulticastDelegate
rather than System.Delegate.

Also remember that += is not an instance operation but actually effectively
something like:

Click = EventHandler.operator+(Click,handler);
rather than
Click.Add(handler);

This allows it to work with Click == null.

For the first handler add you have
Click = EventHandler.operator+(null,handler1); --> Click == handler1
If you add another you have effectively:
Click = EventHandler.operator+(handler1,handler2) --> Click == handler3
where handler3 calls handler1 and handler2


Mar 6 '06 #3
Nick Hounsome wrote:

<snip>
this.btnAccept.Click += new System.EventHandler(this.btnAccept_Click);
The delegate is Click.


No, that's the event. There's no guarantee that it's backed by a simple
delegate. Heck, it might not even be backed by a delegate at all
(although it would be an odd implementation which didn't have a
delegate somewhere).

The only delegate in the above statement is
new EventHandler (this.btnAccept_Click)
The only difference between
"public event EventHandler Click;" and "public EventHandler Click;"
is the operations that you are allowed to perform on the delegate from
outside the class.


No, that's not true. The first declares both a public event (with some
default access methods) *and* a private delegate field. The second
declares just a public delegate field. While the broad result is as you
say, there are other differences some of which (as you said later) you
can detect with reflection. Here's another difference which you can't
detect by reflection though - the first form will lock the monitor
associated with the object it's called on for the duration off
add/remove operations. (In C# 2.0 it could be a different monitor; in
C# 1.1 it's always the containing object or the type for a static
event.)

While events and delegates often look the same, I don't think it's a
good idea to trivialise the differences between them. The difference
between an event and a delegate field is similar to the difference
between a property and a "normal" field. The operations involved
(add/remove for events, set/get for properties) are often implemented
as "straight-through" operations on a field, but they certainly don't
have to be.

<snip>

Jon

Mar 6 '06 #4

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...
Nick Hounsome wrote:

<snip>
> this.btnAccept.Click += new System.EventHandler(this.btnAccept_Click);
The delegate is Click.


No, that's the event. There's no guarantee that it's backed by a simple
delegate. Heck, it might not even be backed by a delegate at all
(although it would be an odd implementation which didn't have a
delegate somewhere).


You are right in that you can override the add and remove so that it doesn't
use a delegate but unless you do the event is effectively a delegate as can
be seen in the debugger.

The only delegate in the above statement is
new EventHandler (this.btnAccept_Click)
The only difference between
"public event EventHandler Click;" and "public EventHandler Click;"
is the operations that you are allowed to perform on the delegate from
outside the class.
No, that's not true. The first declares both a public event (with some
default access methods) *and* a private delegate field. The second
declares just a public delegate field. While the broad result is as you
say, there are other differences some of which (as you said later) you
can detect with reflection. Here's another difference which you can't
detect by reflection though - the first form will lock the monitor
associated with the object it's called on for the duration off
add/remove operations. (In C# 2.0 it could be a different monitor; in
C# 1.1 it's always the containing object or the type for a static
event.)


A different monitor?
While events and delegates often look the same, I don't think it's a
good idea to trivialise the differences between them. The difference
between an event and a delegate field is similar to the difference
between a property and a "normal" field. The operations involved
(add/remove for events, set/get for properties) are often implemented
as "straight-through" operations on a field, but they certainly don't
have to be.


You are right but I still think that it is helpful to think of it this way
at least as a start.
Mar 6 '06 #5
Nick Hounsome <nh***@nickhounsome.me.uk> wrote:
No, that's the event. There's no guarantee that it's backed by a simple
delegate. Heck, it might not even be backed by a delegate at all
(although it would be an odd implementation which didn't have a
delegate somewhere).


You are right in that you can override the add and remove so that it doesn't
use a delegate but unless you do the event is effectively a delegate as can
be seen in the debugger.


Well, I find it helpful to think of it as both a delegate and an event.
From the outside of the class it looks like an event, from the inside
of the class it looks like a delegate. (I haven't actually checked
whether if you use += or -= within the class, it uses the event or the
delegate.)
No, that's not true. The first declares both a public event (with some
default access methods) *and* a private delegate field. The second
declares just a public delegate field. While the broad result is as you
say, there are other differences some of which (as you said later) you
can detect with reflection. Here's another difference which you can't
detect by reflection though - the first form will lock the monitor
associated with the object it's called on for the duration off
add/remove operations. (In C# 2.0 it could be a different monitor; in
C# 1.1 it's always the containing object or the type for a static
event.)


A different monitor?


Yes. In 1.1 it always uses:

lock (this)
{
theDelegate += value;
}

etc

In 2.0 the compiler is free to introduce another variable to hold a
monitor to lock on:

lock (compilerGeneratedVariable)
{
theDelegate += value;
}
While events and delegates often look the same, I don't think it's a
good idea to trivialise the differences between them. The difference
between an event and a delegate field is similar to the difference
between a property and a "normal" field. The operations involved
(add/remove for events, set/get for properties) are often implemented
as "straight-through" operations on a field, but they certainly don't
have to be.


You are right but I still think that it is helpful to think of it this way
at least as a start.


I think we'll have to agree to disagree. I tend to find that if you
tell someone something that's wrong to start with, even if it's meant
to simplify things for the moment, it causes confusion later on.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 6 '06 #6
Ant
Hi guys, thanks for the thoughts. Just to muddy the water further. So far
this is my understanding:

//The real delegate is that which is declared:

delegate void realDelegate(int someParameter);

//Then when you want to use it, you *delegate* something to it by doing this:

someEvent += new realDelegate(someArgument);

//so that 'new realDelgate(someArgumant)' is the delegate only in that it's
delegating the event to the delegate (the abstracted method) which it
instantiates with the new keyword . So it (+= new...) is only called the
delegate because it is delegating to the delegate, but is referred to as the
delegate for simplicity.

Would this be a correct assumption or am I way off the mark?

Thanks
Ant

"Jon Skeet [C# MVP]" wrote:
Nick Hounsome <nh***@nickhounsome.me.uk> wrote:
No, that's the event. There's no guarantee that it's backed by a simple
delegate. Heck, it might not even be backed by a delegate at all
(although it would be an odd implementation which didn't have a
delegate somewhere).


You are right in that you can override the add and remove so that it doesn't
use a delegate but unless you do the event is effectively a delegate as can
be seen in the debugger.


Well, I find it helpful to think of it as both a delegate and an event.
From the outside of the class it looks like an event, from the inside
of the class it looks like a delegate. (I haven't actually checked
whether if you use += or -= within the class, it uses the event or the
delegate.)
No, that's not true. The first declares both a public event (with some
default access methods) *and* a private delegate field. The second
declares just a public delegate field. While the broad result is as you
say, there are other differences some of which (as you said later) you
can detect with reflection. Here's another difference which you can't
detect by reflection though - the first form will lock the monitor
associated with the object it's called on for the duration off
add/remove operations. (In C# 2.0 it could be a different monitor; in
C# 1.1 it's always the containing object or the type for a static
event.)


A different monitor?


Yes. In 1.1 it always uses:

lock (this)
{
theDelegate += value;
}

etc

In 2.0 the compiler is free to introduce another variable to hold a
monitor to lock on:

lock (compilerGeneratedVariable)
{
theDelegate += value;
}
While events and delegates often look the same, I don't think it's a
good idea to trivialise the differences between them. The difference
between an event and a delegate field is similar to the difference
between a property and a "normal" field. The operations involved
(add/remove for events, set/get for properties) are often implemented
as "straight-through" operations on a field, but they certainly don't
have to be.


You are right but I still think that it is helpful to think of it this way
at least as a start.


I think we'll have to agree to disagree. I tend to find that if you
tell someone something that's wrong to start with, even if it's meant
to simplify things for the moment, it causes confusion later on.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 7 '06 #7
Ant wrote:
Hi guys, thanks for the thoughts. Just to muddy the water further. So far
this is my understanding:

//The real delegate is that which is declared:

delegate void realDelegate(int someParameter);
That's the delegate type.
//Then when you want to use it, you *delegate* something to it by doing this:

someEvent += new realDelegate(someArgument);
new realDelegate(someArgument) is the delegate instance.
//so that 'new realDelgate(someArgumant)' is the delegate only in that it's
delegating the event to the delegate (the abstracted method) which it
instantiates with the new keyword . So it (+= new...) is only called the
delegate because it is delegating to the delegate, but is referred to as the
delegate for simplicity.

Would this be a correct assumption or am I way off the mark?


I think you're making it more complicated than it needs to be. I think
"delegate" is generally used for both the type and an instance of the
type, but disambiguating with "delegate type" or "delegate instance" is
good enough (and is what the C# spec uses).

Jon

Mar 7 '06 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Mark Broadbent | last post by:
I have written a class that has a public method which could take some time to complete (20 secs). The idea is for it to raise an event on completion. Should I create a separate thread for this...
3
by: Minh Khoa | last post by:
Please give me more information about delegate and its usage? Why do i use it and when?
11
by: matsi.inc | last post by:
I am looking to make something like a delegate that i can use in my projects but am having a hard time getting started. The behavior I am most interested in is how a delegate changes it's Invoke...
2
by: Tony Johansson | last post by:
Hello! Below I have two different alternativ for where to declare the delegate DoCalculate. Is it possible to say something generally where to declare the delegate. Is best within the class or...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.