delegate confusion

[ohmmega]

hello world.

i would like to implement a class with a timer, witch informs me every
second about it's tick. the code works already, but i would like to
change a thing (or more).

<code>
//at the moment i initialize the object with the constructor:
public myClass(System.Timers.ElapsedEventHandler CallMeBack)
{
System.Timers.Timer myTimer = new System.Timers.Timer(1000);
myTimer.Elapsed += CallMeBack;
myTimer.Enabled = True;
}

//the call from outside (other class) looks like:
myClass myObject = new myClasst(new
System.Timers.ElapsedEventHandler(this.AnsweringMachine));

//with...
private void AnsweringMachine(object sender,
System.Timers.ElapsedEventArgs e)
{
//THAT'S WHAT I WOULD LIKE TO DO:
//someString = ((myClass)sender).getValue();
}
</code>

now to my problem (i commented it already in the code):
sender returns the timer and elapsedeventargs returns the time. i need
access to the calling myObject and it would be very neat to change the
sender and/or the arguments. is there a good solution? i've tried to
inherit from timer but failed, because delegates and events are really
virgin soil for me, so i get confused ` ` o¿o ´ ´

i nearly forgot: i used this implementation, because the polling from
myClass would work completly independent. but would it be wiser to set
a timer in the "outer space" instead of "myClass"?

talked enough.

thanks for putting on the thinking caps...
rené

 

[Alberto Poblacion]

now to my problem (i commented it already in the code):
sender returns the timer and elapsedeventargs returns the time. i need
access to the calling myObject and it would be very neat to change the
sender and/or the arguments. is there a good solution?

One way to do it is to redirect the timer callback into your own routine,
and this routine can in turn call the original callback with the arguments
of your choice, such as "this" for the "sender":


class myClass
{
private System.Timers.ElapsedEventHandler theCallBack;

public myClass(System.Timers.ElapsedEventHandler CallMeBack)
{
this.theCallBack = CallMeBack;
System.Timers.Timer myTimer = new System.Timers.Timer(1000);
myTimer.Elapsed += MyCallback;
myTimer.Enabled = True;
}

private void MyCallback(object sender,
System.Timers.ElapsedEventArgs e)
{
theCallBack(this, e);
}

//(Here goes the rest of class, such as clean-up code for the Timer)
}

 

[james]

ohmmega,

I don't have a compiler on me but I think something along the lines of
this should do what you want. Our anonymous method will handle the
event, and then fire the event handler with myClass as the sender
instead of myTimer.

public myClass(System.Timers.ElapsedEventHandler CallMeBack)
{
System.Timers.Timer myTimer = new System.Timers.Timer(1000);
myTimer.Elapsed += delegate(object sender,
System.Timers.ElapsedEventArgs e)
{
CallMeBack.Invoke(this, e);
};
myTimer.Enabled = True;
}

BTW: You need to make myTimer a member variable or it will get garbage
collected.

Good Luck,
James

 

[Peter Duniho]

now to my problem (i commented it already in the code):
sender returns the timer and elapsedeventargs returns the time. i need
access to the calling myObject and it would be very neat to change the
sender and/or the arguments. is there a good solution? i've tried to
inherit from timer but failed, because delegates and events are really
virgin soil for me, so i get confused ` ` o¿o ´ ´

Alberto has posted one good solution. In his method, the class
initializing the timer essentially makes it look as though it is the class
implementing the timer. It encapsulates the timer itself internally; in
addition to the obvious advantage of addressing your question, it also has
the advantage that the myClass class can change the implementation of the
timer more easily (and even more easily if you change the handler delegate
type to something that myClass defines rather than using the one in the
Timers namespace ).

There are at least two other ways I can think of to address the issue,
which may or may not be appropriate for your needs depending on how you
want it to work.

The first involves simply saving the myClass instance reference and using
that. For example:

public ClientClass
{
myClass myObject;

void SomeMethod()
{
myObject = new myClass(AnsweringMachine);
}

void AnsweringMachine(object sender, ElapsedEventArgs e)
{
someString = myObject.getValue();
}
}

Because the delegate includes a reference to the class instance used to
create the delegate, you can then refer to instance members, such as the
"myObject" field, from within the delegate method.

A variation on the above would be to create a simple class in which you
put the delegate method, and which stores the "myObject" instance. That
way you could create a new instance for each instance of myClass that you
create, if that was desirable for some reason. Of course, you would have
to include in that simple class some way to get back to the ClientClass if
you wanted to be able to do things specific to that instance from within
the callback as well. As you can see, this technique can get arbitrarily
complicated if you want.

Another way to address the issue would be to use an anonymous delegate:

public ClientClass
{
void SomeMethod()
{
myClass myObject;
ElapsedEventArgs callback = delegate(object sender,
ElapsedEventArgs e)
{ someString = myObject.getValue(); }

myObject = new myClass(callback);
}
}

This takes advantage of the fact that the local variable "myObject" is
"captured" by the anonymous delegate. So you can use the variable within
the code of the delegate, and it will retain the value you set it to in
the SomeMethod() method. This might be especially appropriate if the
callback method exists for the sole purpose of handling that one
situation, which is in fact often the case for this sort of thing.

i nearly forgot: i used this implementation, because the polling from
myClass would work completly independent. but would it be wiser to set
a timer in the "outer space" instead of "myClass"?

I don't think it matters. If you have no need to access the timer from
outside myClass, I would say that you should not store it outside
myClass. If the myClass instance itself has no need to access the timer
either, then I would say there's no need to store it even within myClass.

Pete

 

[Peter Duniho]

public myClass(System.Timers.ElapsedEventHandler CallMeBack)
{
System.Timers.Timer myTimer = new System.Timers.Timer(1000);
myTimer.Elapsed += delegate(object sender,
System.Timers.ElapsedEventArgs e)
{
CallMeBack.Invoke(this, e);
};
myTimer.Enabled = True;
}

Any particular reason you prefer the "CallMeBack.Invoke(this, e)" syntax
as opposed to the (IMHO more readable) "CallMeBack(this, e)" syntax? I
believe that in situations where you know the delegate type exactly (as is
the case here), the latter is preferable and somewhat more efficient at
run-time.

BTW: You need to make myTimer a member variable or it will get garbage
collected.

Not true. This code works fine:

static void Start()
{
Timer timer = new Timer();

timer.Elapsed += ElapsedHandler;
timer.Interval = 2000;
timer.Start();
}

static void ElapsedHandler(object sender, ElapsedEventArgs e)
{
Console.WriteLine("timer elapsed");
}

static void Main(string[] args)
{
Start();

GC.Collect();
Console.ReadLine();
}

Pete

 

[Jon Skeet [C# MVP]]

Any particular reason you prefer the "CallMeBack.Invoke(this, e)" syntax
as opposed to the (IMHO more readable) "CallMeBack(this, e)" syntax? I
believe that in situations where you know the delegate type exactly (as is
the case here), the latter is preferable and somewhat more efficient at
run-time.

It's perhaps preferable from a readability point of view, but the
compiled code is the same. The syntax you're suggesting is just sugar
provided by the C# compiler.

 

[Peter Duniho]

It's perhaps preferable from a readability point of view, but the
compiled code is the same. The syntax you're suggesting is just sugar
provided by the C# compiler.

Okay. I read an article that suggested that because Invoke can be used
without knowing the exact delegate signature, some extra run-time stuff
has to happen to handle that syntax. But maybe that referred to a
different way of using the Invoke() method. Or maybe it was just plain
wrong.

 

[james]

Hey Pete,

I tried your code and System.Timers.Timer isn't garbage collected, but
a System.Threading.Timer is garbage collected. Any idea what is going
on here?


static void Start()
{
System.Threading.Timer threadingTimer = new
System.Threading.Timer(delegate
{
Console.WriteLine("System.Threading.Timer");
}, null, 0, 2000);

System.Timers.Timer timersTimer = new
System.Timers.Timer();

timersTimer.Elapsed += delegate
{
Console.WriteLine("System.Timers.Timer");
};
timersTimer.Interval = 2000;
timersTimer.Start();
}


static void Main(string[] args)
{
Start();

GC.Collect();
Console.ReadLine();
}

Thanks,
James

 

[Jon Skeet [C# MVP]]

Okay. I read an article that suggested that because Invoke can be used
without knowing the exact delegate signature, some extra run-time stuff
has to happen to handle that syntax. But maybe that referred to a
different way of using the Invoke() method. Or maybe it was just plain
wrong.

I think that was probably a different Invoke - like Control.Invoke,
etc. Or possibly it was Delegate.DynamicInvoke.

The Invoke method for an individual delegate type is declared by the
delegate itself, with appropriate parameters - which is why it isn't in
the Delegate class.

 

[Peter Duniho]

I think that was probably a different Invoke - like Control.Invoke,
etc. Or possibly it was Delegate.DynamicInvoke.

Here's the article:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=766938&SiteID=1

The reply was from a "moderator MVP", and it appears to me that the
messages are specifically about Invoke on a delegate instance. But I may
have misunderstood.

The Invoke method for an individual delegate type is declared by the
delegate itself, with appropriate parameters - which is why it isn't in
the Delegate class.

Makes sense to me. Obviously, that should be exactly the same as just
calling the delegate as a method.

Pete

 

[Peter Duniho]

I tried your code and System.Timers.Timer isn't garbage collected, but
a System.Threading.Timer is garbage collected. Any idea what is going
on here?

Sure. Those are two entirely different classes. One (Threading.Timer)
specifically notes in the documentation that it must continue to be
referenced, otherwise it will be garbage-collected. The other
(Timers.Timer) does not.

I'm sure that there's some good explanation related to the actual
implementation of the two classes (with Timers.Timer obviously somewhere
else a reference to the instance is kept, whereas with the Threading.Timer
it is not). But the basic fact of the matter is simply that one class
requires you to keep a reference and one does not.

Pete

 

[Jon Skeet [C# MVP]]

Here's the article:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=766938&SiteID=1

The reply was from a "moderator MVP", and it appears to me that the
messages are specifically about Invoke on a delegate instance. But I may
have misunderstood.

It's a pretty confused message, frankly. Calling a method directly is
faster than calling a delegate at all, but using the C# syntax shortcut
is the same as calling Invoke. It doesn't help that the poster brought
in Control.Invoke, which is *very* different from calling Invoke
directly on the delegate.

Makes sense to me. Obviously, that should be exactly the same as just
calling the delegate as a method.

Sort of. I think we're on the same page, but just to check... It's
faster to do:

Foo();

than

ThreadStart t = new ThreadStart(Foo);
t();

.... but the latter is exactly the same as:

ThreadStart t = new ThreadStart(Foo);
t.Invoke();

 

[Peter Duniho]

Sort of. I think we're on the same page, but just to check... It's
faster to do:

Foo();

Yes. By "as a method" I simply meant using the syntax that makes the
delegate look like a regular method.

Pete