Delegates and the Invoke method


D

Dom

I'm teaching myself about delegates and the Invoke method, and I have
a few newbie questions for the gurus out there:

Here are some CSharp statements:
1. public delegate void MyDelegate (int k, string s)
2. MyDelegate MyDelegateVar = MyMethod
3. MyForm.Invoke (MyDelegateVar)

Some questions:

1. What is the meaning of "public" in the first statement? The help
examples always use that. Isn't "private" more appropriate?

2. What is the purpose of "k" and "s" in the parameter list?

3. Isn't this a needless complication over C's pointer to a function,
which did in one statement what is done in two statements above? It
doesn't seem to be any more type-safe than what we had in C.

3. MyForm.Left has a different meaning that MyButton.Left, but what
is the difference between MyForm.Invoke, and MyButton.Invoke? For
that matter, why do we not just have System.Invoke, or something like
that?


Thanks,
Dom
 
Ad

Advertisements

A

Alberto Poblacion

Dom said:
Here are some CSharp statements:
1. public delegate void MyDelegate (int k, string s)
2. MyDelegate MyDelegateVar = MyMethod
3. MyForm.Invoke (MyDelegateVar)

1. What is the meaning of "public" in the first statement? The help
examples always use that. Isn't "private" more appropriate?

It means that "MyDelegate" will be visible from outside of the class
that declares it. If you are only going to use it inside the class then yes,
"private" would be more appropriate.
2. What is the purpose of "k" and "s" in the parameter list?

They are just placeholders used to represent the parameters for the
routines to which the delegate will point. The names themselves are not
significant. You could replace "parameter1" and "parameter2" instead of "k"
and "s", and the declaration of the delegate would be the same.
3. MyForm.Left has a different meaning that MyButton.Left, but what
is the difference between MyForm.Invoke, and MyButton.Invoke?

If MyButton belongs to MyForm they do the same thing: They cause the
delegate to be invoked in the thread that is processing the windows form UI.
Since Form inherits from Control, you are just calling the Invoke method in
the Control class in both cases.
 
N

Nicholas Paldino [.NET/C# MVP]

Dom,

Public is a way of saying that anyone can access the delegate. If you
feel that no one else is going to be able to use the delegate, then by all
means, make it private (as long as you can access it properly from the class
you want to use it in).

k and s in the parameter list are a little superflouous. Technically,
you don't need a parameter name, but for the sake of consistency, it makes
sense. Also, things like intellisense would need to show something when you
try and invoke it. Remember that delegates can have more than one method
associated with them, so you can't just take the parameter names of the
underlying method.

It's absolutely more type-safe. In C, you could set a function pointer
to anything in memory, and when you tried to execute it, the program
crashed. In C#, if the signature does not match, then your program doesn't
compile.

The Form class and the Button class do not have a Left property. If you
declared them on each of those types separately, then they would be
different from Invoke on the Button and the Form class. The reason you see
them on both is because the Button class and the Form class have a common
base type which has the Invoke method declared on it.

Also, you should note that the Invoke method on the Form/Button class is
different from the Invoke method on a delegate. The Invoke method on a
Form/Button instance allows you to pass a delegate to it so that the
delegate is invoked on the thread that created the control.

Hope this helps.
 
D

Dom

Thanks for the info, gives me a better mental picture, but I'm
confused about this.
It's absolutely more type-safe. In C, you could set a function pointer
to anything in memory, and when you tried to execute it, the program
crashed. In C#, if the signature does not match, then your program doesn't
compile.

If I remember by C days, the pointer was declared like this:

int (*ptrFunction) (int, string)

.... and I think the compiler did fail if you set ptrFunction to a
function with the wrong signature. Am I wrong about that?

Dom
 
J

Jon Skeet [C# MVP]

Dom said:
I'm teaching myself about delegates and the Invoke method, and I have
a few newbie questions for the gurus out there:

Here are some CSharp statements:
1. public delegate void MyDelegate (int k, string s)
2. MyDelegate MyDelegateVar = MyMethod
3. MyForm.Invoke (MyDelegateVar)

Some questions:

1. What is the meaning of "public" in the first statement? The help
examples always use that. Isn't "private" more appropriate?

You're declaring the delegate *type* in line 1. Whether it should be
public or not depends on the use, but it's not as if you're making a
field public.
2. What is the purpose of "k" and "s" in the parameter list?

That's up to the documentation for MyDelegate to decide. The names
themselves don't matter, if that's what you're asking about, but it's a
lot easier to write documentation in terms of named parameters than
"the first parameter is..." etc.
3. Isn't this a needless complication over C's pointer to a function,
which did in one statement what is done in two statements above? It
doesn't seem to be any more type-safe than what we had in C.

I find C's pointer-to-function syntax incredibly hard to read, for one
thing. Here, once you've seen the delegate declaration, that's the only
place you need that. Also, as Nicholas points out, it's type safe.
3. MyForm.Left has a different meaning that MyButton.Left, but what
is the difference between MyForm.Invoke, and MyButton.Invoke? For
that matter, why do we not just have System.Invoke, or something like
that?

Control.Invoke effectively marshals a delegate call to the owning
thread for that control. Beyond choosing which thread should be used,
which control you pick makes no difference. However, there may be more
than one UI thread, or none at all, which is why a static method
somewhere wouldn't make sense.
 
J

Jon Skeet [C# MVP]

k and s in the parameter list are a little superflouous. Technically,
you don't need a parameter name, but for the sake of consistency, it makes
sense.

Well, you don't need it in an abstract sense, but the C# compiler
certainly demands it.
 
Ad

Advertisements

N

Nicholas Paldino [.NET/C# MVP]

Absolutely in the abstract sense. Kids demand things all the time that
they don't need.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top