I had always thought of a Delegate as a being more the declaration of a
"signature" of a future Method, rather than as a first-class Type.
It is both.
So I am just asking for some help in understanding why this works.
Actually, Dictionary<theMethodBody, Objectwould be a poor choice, as I'm
not sure how useful a delegate would be as a key, but that's irrelvant...
OK; "theMethodBody" here is the signature, but it also defines a type, with
an .Invoke method matching the signature provided by your
delegate-declaration. The key here is getting your head around
"theMethodBody" actually being a class declaration, similar to (not
correct):
public class theMethodBody : MulticastDelegate {
public Invoke(); // matches declares signature; note also Begin/End Invoke
// ctor is a little different to normal, so not included
}
Thus theMethodBody inherits all the features of MulticastDelegate, such as
GetInvocationList(), plus all those features of Delegate such as the
non-typesafe DynamicInvoke(); however, if you know you have a theMethodBody
instance you can use the type-safe Invoke(). All this is done at compile
time.
(As it happens, "theMethodBody" could be substituted for ThreadStart,
MethodInvoker, etc - as these match on signature. )
At runtime, we can create an instance of "theMethodBody"; as with .Net
generally, this delegate-instance is an object instance:
theMethodBody runMe = new theMethodBody(SomeSuitableMethod);
As you know, I can then invoke this either as runMe(), or runMe.Invoke();
Now suppose I want to run a number of methods (with equal signature) based
on the action a user has performed; then yes, I could have some uber-switch
statement, or I could use a Dictionary of typed-delegates:
Dictionary<int, theMethodBodyactions = new Dictionary<int,
theMethodBody>();
// fill
//blah
// user has selected an option; execute the matching code:
actions[selectedActionIndex].Invoke(); // lazy; no checking for existance
etc
It all "just works"; you could use a similar strategy to craft a bespoke
back-end storage for an event mechanism instead of a delegate instance with
+= and -= (although I'm at a loss for a good reason to do so). If this isn't
helping, I suggest reading up on delegates on MSDN.
Marc
"Bill Woodruff" <bm****@dotscience.comwrote in message
news:ui**************@TK2MSFTNGP05.phx.gbl...
"Marc Gravell" wrote :
>Not sure what the problem is here... what did you expect? theHandler *is*
a type name (declaration); it is a class that derives from
MulticaseDelegate which derives from Delegate which derives from Object.
I happily use delegates in typed collections - on those occasions where I
want a collection of typed delegates!
What is the issue? Sorry if I have missed the point...
... original post by bw snipped for brevity ...
Marc, thanks for your response ! I posted this example because I was
puzzled by being able to do things this way.
I had always thought of a Delegate as a being more the declaration of a
"signature" of a future Method, rather than as a first-class Type.
While a declaration of the form :
Dictionary<Delegate, ObjecttheDictionary = new
Dictionary<Delegate, Object>();
Would have still raised questions in my mind, but would have been easily
acceptable, being able to do :
private delegate void theMethodBody;
Dictionary<theMethodBody, ObjecttheDictionary = new
Dictionary<theMethodBody, Object>();
Somehow seems intutively wrong. So I am just asking for some help in
understanding why this works.
As, so often, the problem being in my assumptions.
thanks, Bill Woodruff
