Delegates are useful, and here is why (sample program)

[raylopez99]

They usually don't teach you in most textbooks I've seen that
delegates can be used to call class methods from classes that are
'unaware' of the delegate, so long as the class has the same signature
for the method (i.e., as below, int Square (int)).

Here is an example to show that feature. Note class "UnAwareCla ss"
has its methods Square and Cuber called by a class DelegateClass.
This is because these methods in UnAwareClass have the same signature
and so they can be called by DelegateClass, without the keyword
'delegate' ever appearing in UnAwareClass.

Note the keyword 'static' has to be used as below, even though
UnAwareClass itself is not static, though there is a way to use
delegates with non-static functions (however I don't see the need to
do so).

Pretty cool if you ask me--like a functor in C++.

RL

//Delegate model showing how another class (“UnAwareClass” ) does not
even have to be aware of the delegate and still be called and
employed.
///

///////
// OUTPUT (takes the square of a number, here 11, and the cube, to
give 121 and 1331)

...now for external use of delegates from two classes...
Square 11 is: 121
!Cube 11 is: 1331
Press any key to continue . . .
///////

using System;
using System.Collecti ons.Generic;
using System.Text;

namespace EventDelegates
{
class Program
{
static void Main(string[] args)
{

UnAwareClass myUnAwareClass = new UnAwareClass();

// now to access delegate from another class

Console.WriteLi ne("...now for external use of delegates from two
classes...");

DelegateClass.P ublicHigherPowe r2 sQr = new
DelegateClass.P ublicHigherPowe r2(UnAwareClass .Square); //!!! Note: how
called: UnAwareClass.Sq uare

DelegateClass myDelegateClass = new DelegateClass() ; //
apparently no ill effects if follows rather than preceeds previous
line

int ji2 = myDelegateClass .DoOp(sQr, 11);

Console.WriteLi ne("Square 11 is: {0}", ji2);

DelegateClass.P ublicHigherPowe r2 Cub2 = new
DelegateClass.P ublicHigherPowe r2(UnAwareClass .Cuber);

//!!! note: how called: UnAwareClass.Cu ber

ji2 = myDelegateClass .DoOp(Cub2, 11);

Console.WriteLi ne(" !Cube 11 is: {0}", ji2);

// !!!Note significance: 'delegate' keyword NEVER APPEARS in class
UnAwareClass (!)

}
}
}
////////////
using System;
using System.Collecti ons.Generic;
using System.Text;

namespace EventDelegates
{
class UnAwareClass
{

//!! in this version, 'delegate' keyword does not appear in
this class (UnAwareClass) but only DelegateClass class

int[] values;
int i;
public UnAwareClass()
{
values = new int[] { 1, 2, 3 }; //not used
i = 22333; //not used
}
public static int Square(int x)
{
return x * x;
}
public static int Cuber(int y)
{
return y * y * y;
}
}

class DelegateClass
{
public delegate int PublicHigherPow er2(int x); //delegate to
be used externally (keyword delegate must of course be declared here)

int j;
public DelegateClass()
{
j = 0;
}

public int DoOp(PublicHigh erPower2 ar, int x) //note format
{
return ar(x);
}
}

}

[raylopez99]

On Jul 19, 10:02*am, raylopez99 <raylope...@yah oo.comwrote:

namespace DelegateSimple0 1
{

* * class Test
* * {
* * * * public delegate void FooEventHandler (int i);

* * * * //public event Action<intFoo;
* * * * public event FooEventHandler Fool;
* * * * public event EventHandler Bar;
* * * * protected void FireBar(EventAr gs args)
* * * * {
* * * * * * Bar(this, args);
* * * * }
* * * * static void Main()
* * * * {
* * * * * * Test t = new Test();
* * * * * * //t.Foo += delegate { Console.WriteLi ne("First"); };

* * * * * * t.Fool += new FooEventHandler (Foo);
* * * * * * t.Bar += delegate { Console.WriteLi ne("Second"); };

* * * * * * t.Fool(10);
* * * * * * t.FireBar(Event Args.Empty);

* * * * }
* * * * static void Foo(int ii)
* * * * {
* * * * * * Console.WriteLi ne("First,hello !");
* * * * }
* * }

}

I discovered a 'required' convention that should be followed for
delegates:

the class event handler registering the event, here, t.Fool += new
FooEventHandler (Foo); or, equivalently, t.Fool += Foo; [*1*] should
have the target method that accepts the parameter, namely the method
Foo (here: static void Foo(int ii)
{ Console.WriteLi ne("First,hello !"); }), in the same class scope as
the class that contains the class event handler (i.e. [*1*] above),
here, Test.

Otherwise, it won't compile. This holds true in Windows Forms too,
and trying to use a scope resolution operators like
"ExternalFormCl ass.Foo" to get to another class in another form did
not work, so, dare I say it, it must be kind of like a "requiremen t",
using the term loosely. Anyway I don't see the harm doing it this
'required' way, even if it's not a requirement.

RL

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yah oo.comwrote:

I discovered a 'required' convention that should be followed for
delegates:

the class event handler registering the event, here, t.Fool += new
FooEventHandler (Foo); or, equivalently, t.Fool += Foo; [*1*] should
have the target method that accepts the parameter, namely the method
Foo (here: static void Foo(int ii)
{ Console.WriteLi ne("First,hello !"); }), in the same class scope as
the class that contains the class event handler (i.e. [*1*] above),
here, Test.

Otherwise, it won't compile.

The part about having the right parameters is a requirement. The part
about being in the same class isn't. The method has to be accessible
though.

Note that this is only incidentally part of events - it's just to do
with how delegate instances are created. Here's an example creating two
Action<intinsta nces using methods in a different class - one of which
is an instance method and one of which is a static method.

using System;

class Foo
{
string name;

public Foo(string name)
{
this.name = name;
}

public static void Print(int i)
{
Console.WriteLi ne("Static: {0}", i);
}

public void PrintWithName(i nt i)
{
Console.WriteLi ne("Instance ({0}): {1}", name, i);
}
}

class Test
{
static void Main()
{
Foo f = new Foo("Bar");
Action<intstati cAction = Foo.Print;
Action<intinsta nceAction = f.PrintWithName ;

staticAction(1) ;
instanceAction( 2);
}
}

This holds true in Windows Forms too,
and trying to use a scope resolution operators like
"ExternalFormCl ass.Foo" to get to another class in another form did
not work, so, dare I say it, it must be kind of like a "requiremen t",
using the term loosely. Anyway I don't see the harm doing it this
'required' way, even if it's not a requirement.

I do, if it means code duplication. If you have the required method
available and accessible somewhere else, it would be a pain to have to
copy the code.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[raylopez99]

On Jul 20, 10:18*am, Jon Skeet [C# MVP] <[e-mail] mwrote:

raylopez99 <raylope...@yah oo.comwrote:

I discovered a 'required' convention that should be followed for
delegates:

the class event handler registering the event, here, t.Fool += new
FooEventHandler (Foo); or, equivalently, t.Fool += Foo; [*1*] should
have the target method that accepts the parameter, namely the method
Foo (here: *static void Foo(int ii)
{ *Console.WriteL ine("First,hell o!"); *}), in the same class scope as
the class that contains the class event handler (i.e. [*1*] above),
here, Test.

Otherwise, it won't compile.

The part about having the right parameters is a requirement. The part
about being in the same class isn't. The method has to be accessible
though.

This is true--but perhaps my problem is this (this is a general
question): how do you access (what scope resolution operator, to use
a C++ term) do you use when you are trying to access a class declared
in a child form from the parent form? As I type this, I believe this
might be impossible in the general case, since the child form might be
instantiated by the parent form and "doesn't exist" unless
instantiated, but I guess we can have two scenarios: one being a
static child form that is already instantiated and the other being a
non-static 'new' child form.

Actually to make the question a bit broader (since I'm learning) how
do you access a class declared in the parent form, from the child
form? I haven't done this, but since a child inhereits the parent I
would imagine it's simply: //from inside the child form:
parentform.pare ntclass.someMet hod(). This second question should be
straightforward .

>
Note that this is only incidentally part of events - it's just to do
with how delegate instances are created. Here's an example creating two
Action<intinsta nces using methods in a different class - one of which
is an instance method and one of which is a static method.

Thanks, but I didn't see how this is relevant, but it reminds me to
study 'Action' at some point, which looks like a sort of macro
shorthand.

This holds true in Windows Forms too,
and trying to use a scope resolution operators like
"ExternalFormCl ass.Foo" to get to another class in another form did
not work, so, dare I say it, it must be kind of like a "requiremen t",
using the term loosely. *Anyway I don't see the harm doing it this
'required' way, even if it's not a requirement.

I do, if it means code duplication. If you have the required method
available and accessible somewhere else, it would be a pain to have to
copy the code.

Perhaps, but the assumption is that you can access this code with a
scope resolution operator. But, if you cannot (see my first question
above) then it's safer to simply recopy the function XYZ that is being
registered into the current class. I.e.--
ParentForm_clas s1.AnEventHandl er += XYZ; //with the understanding XYZ
belongs to 'ParentForm_cla ss1'. If, however, XYZ belongs to the child
form, ChildForm, which may never be instantiated, what then? You
cannot do this: ParentForm_clas s1.AnEventHandl er += ChildForm.XYZ;
in the general case, can you? I don't think so, in the most general
case of 'on-the-fly' child form instantiation from the parent form.

RL

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yah oo.comwrote:

Otherwise, it won't compile.

The part about having the right parameters is a requirement. The part
about being in the same class isn't. The method has to be accessible
though.

This is true--but perhaps my problem is this (this is a general
question): how do you access (what scope resolution operator, to use
a C++ term) do you use when you are trying to access a class declared
in a child form from the parent form? As I type this, I believe this
might be impossible in the general case, since the child form might be
instantiated by the parent form and "doesn't exist" unless
instantiated, but I guess we can have two scenarios: one being a
static child form that is already instantiated and the other being a
non-static 'new' child form.

I don't think you're using the right terminology for a fair amount of
that paragraph, so a code sample would be helpful.

Actually to make the question a bit broader (since I'm learning) how
do you access a class declared in the parent form, from the child
form? I haven't done this, but since a child inhereits the parent I
would imagine it's simply: //from inside the child form:
parentform.pare ntclass.someMet hod(). This second question should be
straightforward .

Again, code would be helpful. I suspect that when you say "a class
declared in the parent form" you mean "a variable declared in the
parent form" but I don't even know whether you mean "parent" in an
inheritance sense or not.

Note that this is only incidentally part of events - it's just to do
with how delegate instances are created. Here's an example creating two
Action<intinsta nces using methods in a different class - one of which
is an instance method and one of which is a static method.

Thanks, but I didn't see how this is relevant

It's relevant because it means you can separate learning about events
from learning about delegates.

but it reminds me to study 'Action' at some point, which looks like a
sort of macro shorthand.

It's not. But if you mean the <Tpart, that's generics - which is a
whole other topic.

This holds true in Windows Forms too,
and trying to use a scope resolution operators like
"ExternalFormCl ass.Foo" to get to another class in another form did
not work, so, dare I say it, it must be kind of like a "requiremen t",
using the term loosely. *Anyway I don't see the harm doing it this
'required' way, even if it's not a requirement.

I do, if it means code duplication. If you have the required method
available and accessible somewhere else, it would be a pain to have to
copy the code.

Perhaps, but the assumption is that you can access this code with a
scope resolution operator.

There's no such operator in C#.

But, if you cannot (see my first question
above) then it's safer to simply recopy the function XYZ that is being
registered into the current class. I.e.--
ParentForm_clas s1.AnEventHandl er += XYZ; //with the understanding XYZ
belongs to 'ParentForm_cla ss1'. If, however, XYZ belongs to the child
form, ChildForm, which may never be instantiated, what then? You
cannot do this: ParentForm_clas s1.AnEventHandl er += ChildForm.XYZ;
in the general case, can you? I don't think so, in the most general
case of 'on-the-fly' child form instantiation from the parent form.

Again, some actual code to talk about would be helpful.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[raylopez99]

On Jul 20, 10:15*pm, Jon Skeet [C# MVP] <[e-mail] mwrote:

>
Again, code would be helpful. I suspect that when you say "a class
declared in the parent form" you mean "a variable declared in the
parent form" but I don't even know whether you mean "parent" in an
inheritance sense or not.

OK, let's call it a variable. A variable declared in the parent form,
but not part of any class. This can be 'found' (scope) in the child
form, yes? I think so. But a variable declared in the child, can it
be found (in the scope) of the parent form? The same problem arises
in Visual Basic when coding for Access dB, and they use dot operator
to resolve scope issues.

but it reminds me to study 'Action' at some point, which looks like a
sort of macro shorthand.

It's not. But if you mean the <Tpart, that's generics - which is a
whole other topic.

No, I meant the keyword 'Action', but it's off topic.

>

Perhaps, but the assumption is that you can access this code with a
scope resolution operator.

There's no such operator in C#.

I know. But if you know C++, the :: would be understood as global
scope. But let's not get hung up in lingo.

>

But, if you cannot (see my first question
above) then it's safer to simply recopy the function XYZ that is being
registered into the current class. *I.e.--
ParentForm_clas s1.AnEventHandl er += XYZ; *//with the understanding XYZ
belongs to 'ParentForm_cla ss1'. *If, however, XYZ belongs to the child
form, ChildForm, which may never be instantiated, what then? *You
cannot do this: *ParentForm_cla ss1.AnEventHand ler += ChildForm.XYZ;
in the general case, can you? *I don't think so, in the most general
case of 'on-the-fly' *child form instantiation from the parent form.

Again, some actual code to talk about would be helpful.

That was the actual code.
"You cannot do this: ParentForm_clas s1.AnEventHandl er +=
ChildForm.XYZ; in the general case, can you? "

The assumption being ChildForm inhereits from Parent form. Frankly
it's a trivial point, if you abide by my 'convention' that I posted
earlier--and every example I've seen in the books abide by this
convention-- you don't need to use a dot operator to give the proper
scope, and using intelliSense, you simply write:
ParentForm_clas s1.AnEventHandl er += .XYZ; since XYZ exists somewhere
as a function in a class in the parent form.

RL

[Jon Skeet [C# MVP]]

On Jul 21, 12:12*pm, raylopez99 <raylope...@yah oo.comwrote:

Again, code would be helpful. I suspect that when you say "a class
declared in the parent form" you mean "a variable declared in the
parent form" but I don't even know whether you mean "parent" in an
inheritance sense or not.

OK, let's call it a variable. *A variable declared in the parent form,
but not part of any class.

How can it be part of a form but not part of a class? Again, please
show some code.

>*This can be 'found' (scope) in the child
form, yes?

Depends on its accessibility. (Personally I try to avoid using fields
which aren't private.)

*I think so. *But a variable declared in the child, can it
be found (in the scope) of the parent form? *

How could it be?

but it reminds me to study 'Action' at some point, which looks like a
sort of macro shorthand.

It's not. But if you mean the <Tpart, that's generics - which is a
whole other topic.

No, I meant the keyword 'Action', but it's off topic.

Action isn't a keyword at all. It's just a delegate type. The C#
compiler has no special knowledge about it.

Perhaps, but the assumption is that you can access this code with a
scope resolution operator.

There's no such operator in C#.

I know. *But if you know C++, the :: would be understood as global
scope. *But let's not get hung up in lingo.

You're making an assumption about C# based on an operator which
doesn't exist in C#. It's impossible to try to correct any mistakes in
your understanding on that basis.

Again, some actual code to talk about would be helpful.

That was the actual code.
"You cannot do this: *ParentForm_cla ss1.AnEventHand ler +=
ChildForm.XYZ; in the general case, can you? *"

And the answer is "You can if XYZ is an accessible static method with
the right signature."

The assumption being ChildForm inhereits from Parent form. *Frankly
it's a trivial point, if you abide by my 'convention' that I posted
earlier--and every example I've seen in the books abide by this
convention-- you don't need to use a dot operator to give the proper
scope, and using intelliSense, you simply write:
ParentForm_clas s1.AnEventHandl er += .XYZ; *since XYZ exists somewhere
as a function in a class in the parent form.

That will never work, as ".XYZ" isn't valid. Or do you mean that's
just the sequence you type, and Intellisense turns it into something
else?

Jon

[Author]

I have been closely following this thread these days. Is it the case
that at the end of the day, delegate is only useful in event handling?

I experimented with multicast delegate with the following code, but
got an exception which says: Attempted to read or write protected
memory. This is often an indication that other memory is corrupt.

The code itself seems to be OK. What does this exception really
mean?

BTW, I don't understand how useful multicast delegate can be. It
seems to me that its only purpose is to "simplify" calling multiple
methods with one call. But all methods have to have the same
signature and all of them have to be registered with the given
multicast delegate. Plus, how often does it happen that multiple
methods have the same signature, return void, and need to be called
one after another? Maybe there are such typical situations in
software development which I don't know?

using System;

namespace ConsoleApplicat ion1
{
public delegate void MulticastDelega te(string s1, string s2);
class MulticastDelega teTest
{
public static void Main(string[] args)
{
MulticastDelega te md = new MulticastDelega te(Method1);
md += new MulticastDelega te(Method2);
md("Just ", "a test.");
Console.ReadKey ();
}
public static void Method1(string s1, string s2)
{
Console.WriteLi ne("M1: " + s1 + s2);
}

public static void Method2(string s1, string s2)
{
Console.WriteLi ne("M2: " + s1 + s2);
}
}
}

[Peter Duniho]

On Mon, 21 Jul 2008 07:47:00 -0700, Author <gn********@gma il.comwrote:

I have been closely following this thread these days. Is it the case
that at the end of the day, delegate is only useful in event handling?

No. I agree that a _multicast_ delegate is most commonly useful for event
handling. But delegates in general are useful in a much broader variety
of scenarios. Any time that you have code that wants to be able to
execute some arbitrary code without knowing what that code is at compile
time, a delegate is useful.

A couple of obvious examples include threaded invocations of code (see
ThreadStart) and collection processing (for example, predicates used for
searching, removing, or otherwise processing a collection).

I experimented with multicast delegate with the following code, but
got an exception which says: Attempted to read or write protected
memory. This is often an indication that other memory is corrupt.

The code itself seems to be OK. What does this exception really
mean?

I don't know...I admit, at first glance the code looks fine to me. But
then, I've been having trouble just "reading" code lately, and I haven't
had a chance to actually try compiling and running it yet. So maybe I've
overlooked something.

BTW, I don't understand how useful multicast delegate can be. It
seems to me that its only purpose is to "simplify" calling multiple
methods with one call. But all methods have to have the same
signature and all of them have to be registered with the given
multicast delegate. Plus, how often does it happen that multiple
methods have the same signature, return void, and need to be called
one after another? Maybe there are such typical situations in
software development which I don't know?

As I mentioned, I think that events are the most obvious and most common
example of the use for multicast delegates. That's a clear example of a
situation in which one might want multiple methods all with the same
signature to all be executed at the same point in code.

You ask "how often does it happen...?" Depending on what you mean, it
happens regularly, or it's not very common. In the sense that events
depend on that model and they are the fundamental basis for a variety of
classes in .NET, including the Forms.Control class, as well as
BackgroundWorke r and various Timer classes. But it's true that often
those events only have one method subscribed, and of course outside of
events the use of a multicast delegate may well be much less common.

But it does happen. :) Not everything in C#/.NET is there for the 90%
scenarios.

Pete

[Jon Skeet [C# MVP]]

On Jul 21, 3:47 pm, Author <gnewsgr...@gma il.comwrote:

I have been closely following this thread these days. Is it the case
that at the end of the day, delegate is only useful in event handling?

No, not at all. Delegates have become more useful over the course of
the evolution of the .NET framework, and they're a core part of LINQ.

I experimented with multicast delegate with the following code, but
got an exception which says: Attempted to read or write protected
memory. This is often an indication that other memory is corrupt.

The code itself seems to be OK. What does this exception really
mean?

Something is very wrong on your machine. It could be the .NET
installation, some bad memory, or something else. The code's fine
though.

BTW, I don't understand how useful multicast delegate can be. It
seems to me that its only purpose is to "simplify" calling multiple
methods with one call. But all methods have to have the same
signature and all of them have to be registered with the given
multicast delegate. Plus, how often does it happen that multiple
methods have the same signature, return void, and need to be called
one after another?

It's very useful for events, to start with. Why should you be limited
to having *one* way of responding to a click, for instance? Multicast
delegates allow for composition of event handlers very neatly.

I've also used them in "Push LNQ" for situations where I've wanted to
compute multiple aggregates from a single input source. I agree that
the uses are relatively limited, but it's still a handy ability.

Jon

[raylopez99]

On Jul 21, 4:41*am, "Jon Skeet [C# MVP]" <[e-mail] mwrote:

>

Again, code would be helpful. I suspect that when you say "a class
declared in the parent form" you mean "a variable declared in the
parent form" but I don't even know whether you mean "parent" in an
inheritance sense or not.

Jon Skeet--here is the code. I think the problem is much more basic:
I don't know how different forms exist in the namespace. See the
comment at "***" below. I assumed they shared the same classes, but
they don't.

I will wait one or two days and check for an answer here, and, if no
answer, I'll make this a separate thread since it's really not so much
a delegate/event question but a namespace/scope question.

Thanks.

RL

public partial class Form1 : Form
{
Class1 myClass1;

public Form1()
{
InitializeCompo nent();

myClass1 = new Class1(100, "hello1");

}

public int myForm1Method()
{
// myClass1 seen here
return 1;
}

////////

Public partial class Form2 : Form
{
Class2 myClass2;
Class1 myNewClass1;
public Form2()
{
InitializeCompo nent();
myClass2 = new Class2();
myNewClass1 = new Class1(99, "helloagain 1");

public int myForm2Method()
{
//***myClass2 seen here, myNewClass1 seen here, but 'myClass1' not
seen here. This is true even if Form2:Form1, and if 'public' added to
classes 1, 2. Why is that?

return 2;
}

}

//////////////

//Class1, class 2 are basically the same

class Class1
{

public string str1;
public int interger1;
public Class1()
{
str1 = "hi";
interger1 = 1;

}
public Class1(int i, string s)
{
str1 = s;
interger1 = i;
}

}
}
//