Help says: might not as often

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

I've seen it happen that timer events occur within a Refresh() method that had user code
The reason I found out was that the this of the timer was occasionally referring to the Grid

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