>>As to my understanding, the native timers are *not* windows events. Viv's test also suggests that they are not, because in that case the timers should have fired many times (autoyield is True in that code) during the for/next loop. Actually, they only started firing after that loop. >
>
>Well, maybe you didn't read the help for DOEVENTS, which states that You can use DOEVENTS for simple tasks such as making it possible for the user to cancel a process after it starts, for example, searching for a file. Long-running processes that yield control of the processor are better performed using a Timer control or delegating the task to a COM Server executable (.exe). . In my understanding, that makes timers the subject of asyncronious processing, at the same level as COM servers, at least in the context of this issue.

Viv's code made clear that a DOEVENTS line will indeed visit the timer frequently. That is not the issue. The issue is: Are there instances of a timer being visited when autoyield=.t. and no doevents line present and also no input-related commands or functions present? Viv's code suggests: NO

>> I think the concept is not well understood by many of us.
>And that's why caution should be taken...

Well, isn't it better to try to understand the concept thoroughly? I must say, I wish some others would jump in here. Ideally, some one from the devteam. They kinda owe it to us, because the documentation isn't clear about it at all.