Of course, the real question was: do many Timers really cause problems? You may want to do some tests with hundreds of Timers, just to see if you detect unusual instability, or other unusual behaviour - before commiting yourself to a solution that doesn't use multiple Timers.

>Thanks Hilmar!
>
>I'm going to look at this and digest it. It may be more than I need to do at this point but I'm going to need a long term solution going forward.
>
>Thanks again for your help and suggestions (as always!) and also about the forwarding. Since the new look of UT I somehow never noticed the CC tab :)
>
>-Kevin
>
>
>>>>Of course, this is a valid concern, and it has to be accounted for. If a Timer fires every 10 seconds and takes more than 10 seconds to execute - or even anything approaching 10 seconds - then a redesign seems appropriate. For instance, execute the timer less often. This is the case, whether you use traditional Timers, or a Timer-wrapper (as we might call the object under discussion: all Timers combined into one).
>
>On the other hand, the Timer-wrapper should be as efficient as possible. To accomodate the possibility of many Timers, you should have the data in a cursor, for fast searching, In my opinion.
>
>My previous idea would have been: fire the Timer-wrapper every 10 seconds. Here is a redesign, which should be more efficient. The idea is to calculate the Interval property every time, adjusting it to the time of the next event. The implementation would be something like this:
>
>At the beginning, check the cursor of timer-events:
>
>* Method SetNextTimer
>select TimerEvents
>set order to "FireAt"
>go top
>and store (FireAt - DateTime()) * 1000 (milliseconds) to the Interval property of your single Timer.
>
>Every time the Timer() Event fires, process the corresponding event, and invoke method SetNextTimer() again. Also, repeat the calculation every time the .AddTimerEvent() method is called.
>
>By the way, if your Timer-wrapper is in a Session class, it can have its own datasession - isolated from other parts of the program. The Session class is available in VFP6 Service Pack 3 or later.
>
>So far, then, my idea is as follows.
>
>Class based on Session Class, or Form class (Form class allows visual design).
>
>Add a Timer Class to it.
>
>(Alternative: just use a Timer object, and have the data in the default datasession.)
>
>Create the cursor TimerEvents, with fields:
>
>
>FireAt T && When should it fire
>Expression M && Expression that should be evaluated at that moment
>Method Init(): sets up the cursor.
>
>Method AddTimerEvent(): Adds a Timer event. Invokes SetNextTimer().
>
>Method SetNextTimer(): Adjusts the Interval property.
>
>Method Timer.Timer(): Executes the desired code, as specified in the cursor. Sees if there are other overdue events, and executes them. Invokes SetNextTimer().