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