Help understanding delegates?

[Brett]

I'd like to better understand how the following code works. I've posted
questions below.

namespace Something.Somet hing1
{
using System;

public delegate void Test1();
public delegate void Test2(ink k);

public class A
{
public static void Log1 (int l)
{
Console.WriteLi ne(":{0}",l);
}

public void Log2 (int l)
{
Console.WriteLi ne("#{0}",l);
}
}

public class Class1
{
public static void Main()
{
A a = new A();
Test2 t0 = new Test2(A.Log1); //use static method
Test2 t1 = new Test2(a.Log2); //use instance method

t0 += t1; t0(0);
t0 -= t1; t0(1);
}
}
}

This will print ":0 #0 :1". How does Log1 print 0 when no param is passed
to it and "l" is not initialized to 0?

What are the differences in the static and instance method calls via
delegates?

This line t0 -= t1; t0(1); removes those methods from the delegate
collection correct? How is the output affected if that line does not
exists?

Also, if I'm using the IE object and have three successive page loads, will
each of the following events respectively fire after each page load rather
than all three always firing after each page load? In other words, after
the first page load completes, onIEDocComplete 1 fires. After the second
page load completes, onIEDocComplete 2 fires. After the third page load
completes, onIEDocComplete 3 fires.

IE_Inst.Documen tComplete += new
SHDocVw.DWebBro wserEvents2_Doc umentCompleteEv entHandler(this .onIEDocComplet e1);

IE_Inst.Documen tComplete += new
SHDocVw.DWebBro wserEvents2_Doc umentCompleteEv entHandler(this .onIEDocComplet e2);

IE_Inst.Documen tComplete += new
SHDocVw.DWebBro wserEvents2_Doc umentCompleteEv entHandler(this .onIEDocComplet e3);

Thanks,
Brett

[Brett]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** @msnews.microso ft.com...

Brett <[e-mail]> wrote:

> What do you mean by "get away with using a collection"?

Perhaps it isn't a collection but just a list, as you have mentioned.

The delegate itself isn't a list - it encapsulates a list of
invocations, but it isn't a list in itself.

When you say that you "still get away with using a collection in this
case" what exactly do you mean?

Probably just do a GetType() to determine it.

I don't see how that would help. Could you give an example of what you
mean?

I don't have an example. Was just trying to get a solid definition of what
this structure is that holds a list of events. First it was something that
behaved like a collection, then it was a list. Then not a list but
something encapsulating a list. One of us is very confused but I'm backing
off now. ; )

Thanks,
Brett

[Jon Skeet [C# MVP]]

Brett <[e-mail]> wrote:

I don't see how that would help. Could you give an example of what you
mean?

I don't have an example. Was just trying to get a solid definition of what
this structure is that holds a list of events. First it was something that
behaved like a collection, then it was a list. Then not a list but
something encapsulating a list. One of us is very confused but I'm backing
off now. ; )

Basically, it contains a list. It's immutable, so you can't change the
list itself, only create a new delegate with a different list
containing the first list. You can't use it as a general purpose
collection, as it can only hold delegates.

The things you've said that confuse me most are:

1) That collections in C# aren't ordered
2) That you've used delegates as collections with no trouble

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

[Brett]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Brett <[e-mail]> wrote:

> I don't see how that would help. Could you give an example of what you
> mean?
I don't have an example. Was just trying to get a solid definition of
what
this structure is that holds a list of events. First it was something
that
behaved like a collection, then it was a list. Then not a list but
something encapsulating a list. One of us is very confused but I'm
backing
off now. ; )

Basically, it contains a list. It's immutable, so you can't change the
list itself, only create a new delegate with a different list
containing the first list. You can't use it as a general purpose
collection, as it can only hold delegates.

The things you've said that confuse me most are:

1) That collections in C# aren't ordered

My fault.
2) That you've used delegates as collections with no trouble I thought they were collections. I've read they were in some of the online
examples I've seen. That's how they are described. That's not a global
description of course. Perhaps this exchange with Mattias further up in
the thread did me in. You see it hits both of your questions.
[>So is a delegate basically a collection of method pointers that when
called,executes all methods in the collection in the order they were added to the
collection?

Correct, except that I believe the order they are called in is
undefined and implementation dependent.]

[Steve Walker]

In message <#5************ **@TK2MSFTNGP10 .phx.gbl>, Brett <[e-mail]>
writes

2) That you've used delegates as collections with no trouble

I thought they were collections. I've read they were in some of the online
examples I've seen. That's how they are described. That's not a global
description of course.

I think this is just a case of terminology. It's quite common to use
"collection " to describe any container which can manage a number of
contained objects. I think Jon is using it in a stricter .NET specific
sense to mean "implements ICollection". I've got lots of classes
implementing IEnumerable which I would casually describe as
"collection s", but by Jon's definition, they aren't.

--
Steve Walker

[Brett]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Brett <[e-mail]> wrote:

> I don't see how that would help. Could you give an example of what you
> mean?

I don't have an example. Was just trying to get a solid definition of
what
this structure is that holds a list of events. First it was something
that
behaved like a collection, then it was a list. Then not a list but
something encapsulating a list. One of us is very confused but I'm
backing
off now. ; )

Basically, it contains a list. It's immutable, so you can't change the
list itself, only create a new delegate with a different list
containing the first list. You can't use it as a general purpose
collection, as it can only hold delegates.

The things you've said that confuse me most are:

1) That collections in C# aren't ordered
2) That you've used delegates as collections with no trouble

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

While we're on the subject,. how can I removed all events I've delegated?
For example:

IE_Inst.Documen tComplete -= new
SHDocVw.DWebBro wserEvents2_Doc umentCompleteEv entHandler(this .onIEDocComplet eGetMessages);

and at some later point clear out
IE_Inst.Documen tComplete

so that no event fires based on the page load complete.

Thanks,
Brett

[Jon Skeet [C# MVP]]

Brett <[e-mail]> wrote:

While we're on the subject,. how can I removed all events I've delegated?
For example:

IE_Inst.Documen tComplete -= new
SHDocVw.DWebBro wserEvents2_Doc umentCompleteEv entHandler(this .onIEDocComplet eGetMessages);

and at some later point clear out
IE_Inst.Documen tComplete

so that no event fires based on the page load complete.

You can only remove specific handlers - so if you know what you've
added, you can remove them again - but you can't just clear out
everything.

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

[mdb]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in
news:MP******** *************** *@msnews.micros oft.com:

You can only remove specific handlers - so if you know what you've
added, you can remove them again - but you can't just clear out
everything.

I think you would be able to iterate through the list of delegates (with
GetInvocationLi st) and remove each one. You probably can even tell whether
its something you've added (versus other classes) with the .Target and/or
..Method properties. Whether you can distinguish between two objects of the
same class with different events might be a bit more difficult, though.

-mdb

[Jon Skeet [C# MVP]]

mdb <m_b_r_a_y@c_t_ i_u_s_a__d0t__c om> wrote:

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in
news:MP******** *************** *@msnews.micros oft.com:

You can only remove specific handlers - so if you know what you've
added, you can remove them again - but you can't just clear out
everything.

I think you would be able to iterate through the list of delegates (with
GetInvocationLi st) and remove each one. You probably can even tell whether
its something you've added (versus other classes) with the .Target and/or
.Method properties. Whether you can distinguish between two objects of the
same class with different events might be a bit more difficult, though.

You can do that if you have access to the delegate - but if you only
have access to the *event*, you can't get the invocation list, only add
to it and remove from it.

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

[Brett]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

mdb <m_b_r_a_y@c_t_ i_u_s_a__d0t__c om> wrote:

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in
news:MP******** *************** *@msnews.micros oft.com:

> You can only remove specific handlers - so if you know what you've
> added, you can remove them again - but you can't just clear out
> everything.

I think you would be able to iterate through the list of delegates (with
GetInvocationLi st) and remove each one. You probably can even tell
whether
its something you've added (versus other classes) with the .Target and/or
.Method properties. Whether you can distinguish between two objects of
the
same class with different events might be a bit more difficult, though.

You can do that if you have access to the delegate - but if you only
have access to the *event*, you can't get the invocation list, only add
to it and remove from it.

Using the example in my initial post, say I add two events to the deletgate
t0. Can I use a foreach loop to get at items stored in the t0 delegate
type?

Now, it isn't necessary that I implement IEnurmerable to use a for each
loop? I ask that question because every time I have used a for each loop, I
haven't implemented IEnumerable. However, from the docs:
[IEnumerable must be implemented to support the ForEach semantics of
Microsoft Visual Basic. COM classes that allow enumerators also implement
this interface.]

If the above is true, then t0 is a collection because IEnumerable is in the
System.Collecti ons namespace.

Brett

[Sean Hederman]

"Brett" <[e-mail]> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message [Snip]

You can do that if you have access to the delegate - but if you only
have access to the *event*, you can't get the invocation list, only add
to it and remove from it.

Using the example in my initial post, say I add two events to the
deletgate t0. Can I use a foreach loop to get at items stored in the t0
delegate type?

IF you have access to the delegate object itself you can foreach through
Delegate.GetInv ocationList which is an array. Arrays implement IList which
inherits from IEnumerable via ICollection.
Now, it isn't necessary that I implement IEnurmerable to use a for each
loop? I ask that question because every time I have used a for each loop,
I haven't implemented IEnumerable. However, from the docs:
[IEnumerable must be implemented to support the ForEach semantics of
Microsoft Visual Basic. COM classes that allow enumerators also implement
this interface.]
The object you are enumerating on must implement IEnumerable (the one in the
"in" part of your foreach).
If the above is true, then t0 is a collection because IEnumerable is in
the System.Collecti ons namespace.
Sorry, wrong. DictionaryEntry , Comparer, and IHashCodeProvid er are all in
the System.Collecti ons namespace and are not collections. Being in the
namespace does not imply that they ARE collections, merely that they are
related to collections in some way. You're confusing location with identity.
Just to reinforce my point, t0.GetInvocatio nList returns an array which IS a
collection (since it implements ICollection), but Array resides in the
System namespace.
Brett