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)
}

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 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