By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,738 Members | 1,730 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,738 IT Pros & Developers. It's quick & easy.

Delegates

P: n/a
im having problems trying to understand the delegates in
c#, does anybody know some link where i can find a good
and simple explanation?

thanks
Nov 15 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
kode,

Check out the section of the .NET framework documentation titled
"Delegates Tutorial", located at (watch for line wrap):

http://msdn.microsoft.com/library/de...estutorial.asp

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"kode" <an*******@discussions.microsoft.com> wrote in message
news:00****************************@phx.gbl...
im having problems trying to understand the delegates in
c#, does anybody know some link where i can find a good
and simple explanation?

thanks

Nov 15 '05 #2

P: n/a
there's also a pretty good chapter in Jesse Liberty's C#
book, which just happens to be available FREE ONLINE
http://www.oreilly.com/catalog/progc...hapter/ch12.pd
f

cheers!

btw his discussion of why events have the accessors they
do is dumb, but that's another story..

-----Original Message-----
kode,

Check out the section of the .NET framework documentation titled"Delegates Tutorial", located at (watch for line wrap):

http://msdn.microsoft.com/library/default.asp? url=/library/en-us/csref/html/vcwlkdelegatestutorial.asp
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"kode" <an*******@discussions.microsoft.com> wrote in messagenews:00****************************@phx.gbl...
im having problems trying to understand the delegates in c#, does anybody know some link where i can find a good
and simple explanation?

thanks

.

Nov 15 '05 #3

P: n/a
would b hacker <al****@digitalword.net> wrote:
btw his discussion of why events have the accessors they
do is dumb, but that's another story..


What's "dumb" about it? Makes perfect sense to me.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #4

P: n/a
the problem with the event model is that it offers an add-
remove syntax which prevents retrieving any delegates
that have been assigned to the event. this means that
you can't retrieve event handlers in reflection, for
instance you can't copy event handlers from one object to
another.

according to liberty, this is to prevent objects with
access to the event (Main in liberty's example) from
impersonating the event (Main causing the printing of a
fictitious time on the console). this kind of issue is
silly, of coures main can do all kinds of wierd stuff if
it really wants, requiring that main not hijack events
should be a matter of style not language grammar.

btw does anybody know if there is a pre-c# history to the
event model that c# simply copied, or is the add/remove
event model novel with c#?

-----Original Message-----
would b hacker <al****@digitalword.net> wrote:
btw his discussion of why events have the accessors they do is dumb, but that's another story..


What's "dumb" about it? Makes perfect sense to me.

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

Nov 15 '05 #5

P: n/a
The concern is more about accidental problems as opposed to malicious
intent. If you could assign directly, you'd be able to write:

appDomain.DomainLoadEvent = new EventHandler(routine);

If somebody was already hooked up to the event, you would have just unhooked
them. Which would be bad.
--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"wood bee hacker" <al****@digitalword.net> wrote in message
news:02****************************@phx.gbl...
the problem with the event model is that it offers an add-
remove syntax which prevents retrieving any delegates
that have been assigned to the event. this means that
you can't retrieve event handlers in reflection, for
instance you can't copy event handlers from one object to
another.

according to liberty, this is to prevent objects with
access to the event (Main in liberty's example) from
impersonating the event (Main causing the printing of a
fictitious time on the console). this kind of issue is
silly, of coures main can do all kinds of wierd stuff if
it really wants, requiring that main not hijack events
should be a matter of style not language grammar.

btw does anybody know if there is a pre-c# history to the
event model that c# simply copied, or is the add/remove
event model novel with c#?

-----Original Message-----
would b hacker <al****@digitalword.net> wrote:
btw his discussion of why events have the accessors they do is dumb, but that's another story..


What's "dumb" about it? Makes perfect sense to me.

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

Nov 15 '05 #6

P: n/a
wood bee hacker <al****@digitalword.net> wrote:
the problem with the event model is that it offers an add-
remove syntax which prevents retrieving any delegates
that have been assigned to the event. this means that
you can't retrieve event handlers in reflection, for
instance you can't copy event handlers from one object to
another.
Which is good in many ways - if a class *wants* to expose which
handlers are being used, it can do so, but it doesn't *have* to.
according to liberty, this is to prevent objects with
access to the event (Main in liberty's example) from
impersonating the event (Main causing the printing of a
fictitious time on the console). this kind of issue is
silly, of coures main can do all kinds of wierd stuff if
it really wants, requiring that main not hijack events
should be a matter of style not language grammar.
No, because it helps to stop mistakes happening, just like strong
typing, access modifiers and the like. Would you suggest that
everything should be public as well? It's the same kind of argument.
btw does anybody know if there is a pre-c# history to the
event model that c# simply copied, or is the add/remove
event model novel with c#?


Don't know, to be honest.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #7

P: n/a
I can still app hijack with PostMessage and subclassing outside the runtime.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
wood bee hacker <al****@digitalword.net> wrote:
the problem with the event model is that it offers an add-
remove syntax which prevents retrieving any delegates
that have been assigned to the event. this means that
you can't retrieve event handlers in reflection, for
instance you can't copy event handlers from one object to
another.


Which is good in many ways - if a class *wants* to expose which
handlers are being used, it can do so, but it doesn't *have* to.
according to liberty, this is to prevent objects with
access to the event (Main in liberty's example) from
impersonating the event (Main causing the printing of a
fictitious time on the console). this kind of issue is
silly, of coures main can do all kinds of wierd stuff if
it really wants, requiring that main not hijack events
should be a matter of style not language grammar.


No, because it helps to stop mistakes happening, just like strong
typing, access modifiers and the like. Would you suggest that
everything should be public as well? It's the same kind of argument.
btw does anybody know if there is a pre-c# history to the
event model that c# simply copied, or is the add/remove
event model novel with c#?


Don't know, to be honest.

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

Nov 15 '05 #8

P: n/a
news.microsoft.com <an********@discussions.microsoft.com> wrote:
I can still app hijack with PostMessage and subclassing outside the runtime.


Sure. It's not absolutely preventing you from doing horrible thing -
but it's making life easier for those of us who don't *want* to do
nasty things, but would make mistakes if it were really easy to do
those things.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #9

P: n/a
Its something .NET should have addressed. An unsecure app message queue.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
news.microsoft.com <an********@discussions.microsoft.com> wrote:
I can still app hijack with PostMessage and subclassing outside the
runtime.
Sure. It's not absolutely preventing you from doing horrible thing -
but it's making life easier for those of us who don't *want* to do
nasty things, but would make mistakes if it were really easy to do
those things.

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

Nov 15 '05 #10

P: n/a
news.microsoft.com <di********@discussion.microsoft.com> wrote:
Its something .NET should have addressed. An unsecure app message queue.


But that's completely unrelated to whether or not the idea of events is
good or not.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #11

P: n/a
i agree, with caveat below, and you raise a very
reasonable concern-- but also one that i would address
very simply. seems to me that the correct way to enable
reflection would be to change the "add/remove" paradigm
to "add/remove/get". then for instance to do a copy you
would use get followed by a += loop. your accidental
problem below wouldnt happen because there is no "set".
you might not even call the new accessor "get" but rather
a cast of the event to a MulticastDelegate.

now the caveat: the current model actually DOES allow
you to write the accidental errant code exactly as you
just proposed-- provided 2 conditions are met. First,
your errant code must appear in the class which declares
the event rather than in a different class-- admittedly
not a common scenario since it is normally external
objects which register event handlers. Second, the event
must have been declared using the (more common) variable-
declarators form rather than the member-name (accessor)
form.

voila: i kid you not-- try it! if you write the
statement in one class you get a compiler error, in
another class you don't (even though the declaration is
marked "public"). if you declare the event using one
syntax you get a compiler error, using the alternate
syntax you don't. now i bet you didnt know that, and i
bet most programmers don't know that, so i submit that if
you dont agree with me that the event grammar is bogus,
you should at least agree that it is OBSCURE.

back to working with reality the way it is, do you happen
to know who actually designed this into the c# grammar?
are there any discussion threads or anybody who would
remember what they were actually thinking or where they
got their model or inspiration from? i am indeed
curious!!
-----Original Message-----
The concern is more about accidental problems as opposed to maliciousintent. If you could assign directly, you'd be able to write:
appDomain.DomainLoadEvent = new EventHandler(routine);

If somebody was already hooked up to the event, you would have just unhookedthem. Which would be bad.
--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights."wood bee hacker" <al****@digitalword.net> wrote in messagenews:02****************************@phx.gbl...
the problem with the event model is that it offers an add- remove syntax which prevents retrieving any delegates
that have been assigned to the event. this means that
you can't retrieve event handlers in reflection, for
instance you can't copy event handlers from one object to another.

according to liberty, this is to prevent objects with
access to the event (Main in liberty's example) from
impersonating the event (Main causing the printing of a
fictitious time on the console). this kind of issue is
silly, of coures main can do all kinds of wierd stuff if it really wants, requiring that main not hijack events
should be a matter of style not language grammar.

btw does anybody know if there is a pre-c# history to the event model that c# simply copied, or is the add/remove
event model novel with c#?

>-----Original Message-----
>would b hacker <al****@digitalword.net> wrote:
>> btw his discussion of why events have the accessors

they
>> do is dumb, but that's another story..
>
>What's "dumb" about it? Makes perfect sense to me.
>
>--
>Jon Skeet - <sk***@pobox.com>
>http://www.pobox.com/~skeet
>If replying to the group, please do not mail me too
>.
>

.

Nov 15 '05 #12

P: n/a
wood bee hacker <al****@digitalword.net> wrote:
i agree, with caveat below, and you raise a very
reasonable concern-- but also one that i would address
very simply. seems to me that the correct way to enable
reflection would be to change the "add/remove" paradigm
to "add/remove/get". then for instance to do a copy you
would use get followed by a += loop. your accidental
problem below wouldnt happen because there is no "set".
you might not even call the new accessor "get" but rather
a cast of the event to a MulticastDelegate.
If you want to provide that functionality, I don't believe there's
anything stopping you from doing so - you can write your own code to
store the event handlers, and then provide a way of accessing them.
now the caveat: the current model actually DOES allow
you to write the accidental errant code exactly as you
just proposed-- provided 2 conditions are met. First,
your errant code must appear in the class which declares
the event rather than in a different class-- admittedly
not a common scenario since it is normally external
objects which register event handlers. Second, the event
must have been declared using the (more common) variable-
declarators form rather than the member-name (accessor)
form.

voila: i kid you not-- try it!
No need to, I believe you.
if you write the
statement in one class you get a compiler error, in
another class you don't (even though the declaration is
marked "public").
And that's pretty reasonable, given the intention. I don't think it's
that odd to automatically give the class itself rather more control
over the event.
if you declare the event using one
syntax you get a compiler error, using the alternate
syntax you don't. now i bet you didnt know that, and i
bet most programmers don't know that, so i submit that if
you dont agree with me that the event grammar is bogus,
you should at least agree that it is OBSCURE.
It's obscure, but you won't run into it unless you're trying to do
something that very few people will want or need to do. I don't have
much of a problem with that. I also don't *think* it's guaranteed by
the C# spec - it's due to the way that the MS C# compiler *happens* to
pick the same variable name for the field as for the event (rather than
__eventName as the C# spec example suggests as a possibility). *That*
is a bit of a pity, I agree. (In that people may start relying on it
when they shouldn't.)
back to working with reality the way it is, do you happen
to know who actually designed this into the c# grammar?
are there any discussion threads or anybody who would
remember what they were actually thinking or where they
got their model or inspiration from? i am indeed
curious!!


I don't know of any discussions about it - but then I arrived fairly
late on the C# scene.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #13

P: n/a
thanks jon, especially for the insight about fields v
events!

here's a simple thing i want to do, is there a simple or
standard way to do it? i want to VSDesigner a template
TreeView object and copy it at runtime to a new TreeView
() object. i can copy the properties no problem using
reflection, how do i copy the events?

known but tacky solutions are: manually += the events in
code rather than Designer (yuk), or wrap TreeView and
manually supply the functionality as you mention
previously (awkward, and breaks if TreeView changes).

thanks in advance!

-----Original Message-----
wood bee hacker <al****@digitalword.net> wrote:
i agree, with caveat below, and you raise a very
reasonable concern-- but also one that i would address
very simply. seems to me that the correct way to enable reflection would be to change the "add/remove" paradigm to "add/remove/get". then for instance to do a copy you would use get followed by a += loop. your accidental
problem below wouldnt happen because there is no "set". you might not even call the new accessor "get" but rather a cast of the event to a MulticastDelegate.
If you want to provide that functionality, I don't

believe there'sanything stopping you from doing so - you can write your own code tostore the event handlers, and then provide a way of accessing them.
now the caveat: the current model actually DOES allow
you to write the accidental errant code exactly as you
just proposed-- provided 2 conditions are met. First,
your errant code must appear in the class which declares the event rather than in a different class-- admittedly not a common scenario since it is normally external
objects which register event handlers. Second, the event must have been declared using the (more common) variable- declarators form rather than the member-name (accessor) form.

voila: i kid you not-- try it!
No need to, I believe you.
if you write the
statement in one class you get a compiler error, in
another class you don't (even though the declaration is marked "public").


And that's pretty reasonable, given the intention. I

don't think it'sthat odd to automatically give the class itself rather more controlover the event.
if you declare the event using one
syntax you get a compiler error, using the alternate
syntax you don't. now i bet you didnt know that, and i bet most programmers don't know that, so i submit that if you dont agree with me that the event grammar is bogus, you should at least agree that it is OBSCURE.
It's obscure, but you won't run into it unless you're

trying to dosomething that very few people will want or need to do. I don't havemuch of a problem with that. I also don't *think* it's guaranteed bythe C# spec - it's due to the way that the MS C# compiler *happens* topick the same variable name for the field as for the event (rather than__eventName as the C# spec example suggests as a possibility). *That*is a bit of a pity, I agree. (In that people may start relying on itwhen they shouldn't.)
back to working with reality the way it is, do you happen to know who actually designed this into the c# grammar? are there any discussion threads or anybody who would
remember what they were actually thinking or where they got their model or inspiration from? i am indeed
curious!!
I don't know of any discussions about it - but then I

arrived fairlylate on the C# scene.

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

Nov 15 '05 #14

P: n/a
wood bee hacker <al****@digitalword.net> wrote:
thanks jon, especially for the insight about fields v
events!

here's a simple thing i want to do, is there a simple or
standard way to do it? i want to VSDesigner a template
TreeView object and copy it at runtime to a new TreeView
() object. i can copy the properties no problem using
reflection, how do i copy the events?
Well, I'd suggest using Clone, but that doesn't exist for TreeView. Of
course, you could derive from TreeView yourself, and call
Object.MemberwiseClone from there, but then I suspect your event
handlers would be really tied to each other.
known but tacky solutions are: manually += the events in
code rather than Designer (yuk), or wrap TreeView and
manually supply the functionality as you mention
previously (awkward, and breaks if TreeView changes).


I don't know of any other way, to be honest.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #15

P: n/a
--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"wood bee hacker" <al****@digitalword.net> wrote in message
news:08****************************@phx.gbl...
i agree, with caveat below, and you raise a very
reasonable concern-- but also one that i would address
very simply. seems to me that the correct way to enable
reflection would be to change the "add/remove" paradigm
to "add/remove/get". then for instance to do a copy you
would use get followed by a += loop. your accidental
problem below wouldnt happen because there is no "set".
you might not even call the new accessor "get" but rather
a cast of the event to a MulticastDelegate.
Can you explain the scenario where you need to do this?

now the caveat: the current model actually DOES allow
you to write the accidental errant code exactly as you
just proposed-- provided 2 conditions are met. First,
your errant code must appear in the class which declares
the event rather than in a different class-- admittedly
not a common scenario since it is normally external
objects which register event handlers. Second, the event
must have been declared using the (more common) variable-
declarators form rather than the member-name (accessor)
form.
A class that defines the event owns the underlying delegate, and can do
whatever it wants to it. It needs full access so that it can do things such
as calling GetInvocationList(). This is roughly analogous to properties, in
which the defining class has full control of the backing store.

voila: i kid you not-- try it! if you write the
statement in one class you get a compiler error, in
another class you don't (even though the declaration is
marked "public"). if you declare the event using one
syntax you get a compiler error, using the alternate
syntax you don't. now i bet you didnt know that, and i
bet most programmers don't know that, so i submit that if
you dont agree with me that the event grammar is bogus,
you should at least agree that it is OBSCURE.
If you use the advanced syntax - and it's pretty rare that you would *want*
to do so - you can cause the same problems if you write your code
incorrectly.
back to working with reality the way it is, do you happen
to know who actually designed this into the c# grammar?
are there any discussion threads or anybody who would
remember what they were actually thinking or where they
got their model or inspiration from? i am indeed
curious!!
The feature was designed by the C# language design team, and I was a member
at the time we did events.



-----Original Message-----
The concern is more about accidental problems as opposed

to malicious
intent. If you could assign directly, you'd be able to

write:

appDomain.DomainLoadEvent = new EventHandler(routine);

If somebody was already hooked up to the event, you

would have just unhooked
them. Which would be bad.
--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and

confers no rights.
"wood bee hacker" <al****@digitalword.net> wrote in

message
news:02****************************@phx.gbl...
the problem with the event model is that it offers an add- remove syntax which prevents retrieving any delegates
that have been assigned to the event. this means that
you can't retrieve event handlers in reflection, for
instance you can't copy event handlers from one object to another.

according to liberty, this is to prevent objects with
access to the event (Main in liberty's example) from
impersonating the event (Main causing the printing of a
fictitious time on the console). this kind of issue is
silly, of coures main can do all kinds of wierd stuff if it really wants, requiring that main not hijack events
should be a matter of style not language grammar.

btw does anybody know if there is a pre-c# history to the event model that c# simply copied, or is the add/remove
event model novel with c#?
>-----Original Message-----
>would b hacker <al****@digitalword.net> wrote:
>> btw his discussion of why events have the accessors
they
>> do is dumb, but that's another story..
>
>What's "dumb" about it? Makes perfect sense to me.
>
>--
>Jon Skeet - <sk***@pobox.com>
>http://www.pobox.com/~skeet
>If replying to the group, please do not mail me too
>.
>

.

Nov 15 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.