>>Hi Gregory,
>>
>>From the MSDN:
>>
>>Applications that do not use high-resolution timing should use the SetTimer function instead of multimedia timer services. The timer services provided by SetTimer post WM_TIMER messages to a message queue, while the multimedia timer services call a callback function. Applications that want a waitable timer should use the CreateWaitableTimer function.
>>
>>If we can believe the above, the timer events queue up until VFP has a chance to process them. In your test, I suspect the Fox is getting it's britches yanked down at a most inappropriate time. I'm sure we all agree that the native timer does have some drawbacks, but I can live with that for the stability and simplicity.
>>
>>>There must be a good reason why vfp saves the events and gives a burst afterwards.
>>>The callback fll has bugs
>>>
>>>I suspect vfp turns off timer events during critical operations (eg update). After that the number of missed events is calculated and caught up (the burst)
>
>hi Jim,
>
>I see. Just tested with SetTimer() using the callback function.
>
>(1) The vfpcode is not interrupted (during update and replace)
>(2) The callback function is only called twice (even with 50 ms time-out value)
>(3) No crash ;-)
>
>I guess vfp does really calculate the missed events, given that the test was only interrupted twice (I turn off the timer after the End Replace)

And I suspect that the VFP code reached a 'wait' state at some point, allowing those 2 events to process :-) Makes perfect sense to me. Not knowing the underlying C/C++ that those long running commands encompass, I surely cannot determine when it is safe to allow the switch to my timer code. If timing is that critical in an app, VFP is probably not the proper tool (nor Windows the OS). IMHO.