I don't quite your comment that Timers can fire after every foxpro statement

That would mean that if I write, for instance, a Scan loop, that a timer might be called at any time to reset the current work area, wouldn't it? That ALL code anywhere that relied on the current work area would be susceptible to this?

In my own work years ago on PEM Editor, I saw timers (with brief intervals) that got stacked up during the execution of a longer piece of code. They certainly did not interrupt that code; they waited until that code was done before all the timer calls were executed.

Certainly the Help file indicates that; thus

If your application or another application is making heavy demands on the system — such as long loops, intensive calculations, or disk, network, or port access — your application might not get timer events as often as the Interval property specifies.

That would only make sense if the timer event was handled like all other events, in line, one after another.



>>
>>I thought timers did not interrupt an executing method.
>>
>
>Oh, but they do. Timers can fire after every foxpro statement. If the statement calls a udf, then after every statement of that function