>>
>>>Interrupt handlers fire at indeterminate times.
>>
>>Not strictly true. The interrupt may fire at any time, when or whether your handler processes it is up to you (i.e. VFP). Your point about well-behaved interrupt handlers is valid but the question here is simply whether Peter can safely rely on _TALLY immediately following a select. AFAIK a timer message just gets stuck in the windows message queue along with everything else (albeit possibly with a higher priority). The documentation for Autoyield=.F. clearly states :
>>
>>"The instance of Visual FoxPro does not process pending Windows events between each line of user program code.
>>All pending Windows events are placed in a queue, and the events in the queue are processed when DOEVENTS is issued or a wait state occurs. A wait state occurs when Visual FoxPro is waiting for input from the user. The WAIT command does not create a wait state."
>>
>>and my test seems to bear this out. Like you I'm prepared to err on the side of caution but unless someone can demonstrate that it *CAN BE* rather than just *MAY BE* a problem I'll categorise it as 'Fear and Superstition'
>>
>>Regards,
>>Viv
>
>Viv,
>
>I think that a timer may fire between each line of code, provided autoyield is TRUE. (Maybe a timer is set up in such a way that it uses a windows event)
>
>I've had the case where a grid refesh used some dynamic* and the dynamic* used functions to return eg the forecolour.
>
>The timer interrupted those functions

Greg, I'm quite interested in a piece of code that demonstrates this...