Walter,

You are right. I am wrong.

I was going by code that I believe I saw in the free VMF framework a few years ago, but I no longer have that on my machines to check it out. It was something that I always kept in the back of my mind.

In any case, looking further into this, it looks like it is VFP INTERNAL things that can interfere, NOT external processes. From "The Fundamentals..." by Whil Hentzen:
"The timer does not process when a menu bar, pull-down menu or popup menu is open. For example, you can cause something to happen when the timer event is fired, such as a WAIT WINDOW command or a message dialog, and the Timer control keeps ticking." (by this I think he means it does not fire, even though the interval may lapse several times during the specific VFP process)

Back when I had VMF (VFP 3 then, I think) I thought I had constructed a test where, indeed, I got multiple event firings IN A ROW (they had been "due" but could not be processed at the correct time so had 'stacked up' until they could) but I guess my memory is bad on this.

Thanks for the correction.

JimN

>Hi Jim,
>
>>No, in the case that the interval *has* expired (maybe 10 minutes ago, maybe 3 hours ago) once the app. REGAINS control, it will fire. If it was 3 hours ago and you have 2hours set, then you will get 2 immediate fires.
>
>>This is true regardless of the interval. With a very short interval you will get as many fires as have occurred too, all at once, upon the app. regaining control.
>
>Are you sure ? As I recall correctly and have used in several programs, Timers also fire when VFP does not have the focus.
>
>Walter,