>>Were you using a loop to keep VFP "busy" while a timer tried to fire? If so, if you include DOEVENTS in the loop, do you notice any difference?
>
>Yes, I am using a loop to keep VFP busy. Great suggestion on including a DOEVENTS in the loop. Unfortunately, the timer still waits until the loop is done even with the DOEVENTS in the loop.

Back in the VFP5/6 days, Bela Bodecs created a timer replacement FLL, which though old is still available today: http://www.levelextreme.com/ViewPageNewDownload.aspx?ID=9315 . I haven't had a need for something like that so I've never tested it. In the readme of that download, he outlines one case where (at least in the 5/6 days) a timer wouldn't fire: if it's in Form1, while another, modal Form2 is also running.

HackFox 3 ( I don't have the earlier version ) lists some cases where the VFP timer won't fire:

- while a menu is activated/dropped
- if placed in a toolbar
- while resizing, dragging or scrolling a window in VFP

I don't know if any of these issues improved with later versions of VFP ( 3 was pretty nasty ).

I thought at one point a FoxWiki article might have been put together outlining the limitations of the VFP native timer, but I couldn't find anything like that there.

I believe Bela wrote the FLL to address some of the shortcomings of the native VFP timer. I don't know if the latter in VFP9 are still subject to the problems of 5/6. Experimenting with the FLL might be useful for those wanting to do a lot of work with timers, or who are looking for more reliability.

Overall, though, if anyone is contemplating code that may have to run simultaneously ( multithreading/multiprocessing ), they're probably better off spawning separate processes that can be scheduled to run on separate threads/CPU cores. I've never played around with VFP MTDLLs but my understanding is there are complications in using them, and limitations in what they can achieve. Completely separate VFP processes can be fairly small by current standards.