>>>Why is a timer an element of user interface??
>>
>>Paul, I'm not entirely sure why, but I suspect that it's a matter of the interface to the Windows Event loop that causes the problem; the single best clear indication of this is that I've had standalone timer objects failing to trigger in a tight loop without the introduction of a DOEVENTS to the loop. Perhaps you have a better explanation for this behavioral anomaly?
>
>I surely do have a better explanation: VFP is not multithreaded. Basically, it's impossible to have a reliable timer in a single threaded app.
>
>When I say that timers are not user interface elements I mean that they can be used in VFP apps without any UI.
>

That's true, but they are UI elements in that they can only respond when the VFP Event loop can process them, as when a DOEVENTS is executed.

AFA a reliable timer under a single-threaded app, that's not really true if yuou're willing to live within the constraints of polled detection of the timer events; a timer could be started out-of-process and provide a pollable shared resource to detect that the timer has terminated. It might even be possible through a COM interface and the VFPCOM utility to create a COM-based out-of-process timer that produced a detectable event within VFP; if this were the case, it would be able to be dispatched between atomic VFP instructions. I haven't tried, but the base capability to create a timer outside the process exists, and the ability to wrap VFP code around an event from an out-of-process server also exists.

>Vlad