On Thu, 26 Jul 2007 07:40:19 -0700, ohmmega <sh****@gmx.atw rote:
now to my problem (i commented it already in the code):
sender returns the timer and elapsedeventarg s 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(Answeri ngMachine);
}
void AnsweringMachin e(object sender, ElapsedEventArg s e)
{
someString = myObject.getVal ue();
}
}
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;
ElapsedEventArg s callback = delegate(object sender,
ElapsedEventArg s e)
{ someString = myObject.getVal ue(); }
myObject = new myClass(callbac k);
}
}
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
