Yeah, the whole reason I started looking at these timers was because we are having a problem where the form with all the timers on it is somehow becoming active even when there is a modal form in front of it. This occurs when a user double clicks in the grid of the main form real fast (which calls the second form). Once this happens the menu is still active and the main form is somewhat active (tooltips show and you can click on items on the grid) but nothing else. And in the modal form nothing is active. At this point the only way you can exit is with ctrl-alt-delete. I've removed and reworked some of the timers but we still are having this problem and it seems much worse on faster machines. Maybe I should repost this problem under a different heading??

-Kevin

>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 Universal Thread 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().
"The earth is but one country, and mankind its citizens." (From the Holy Scriptures of the Bahá'í Faith)