Hi,

>>There should be no reason for this under normal situations. Consequently, in the case of _tally I disagree with your POV.
>
>If you don't see the difference between normal code and an interrupt handler the discussion really can't go very far.
>
>Normal code flows predictably. Interrupt handlers fire at indeterminate times, since they never know what they have interrupted they have to be coded in a manner such that the interrupted code can continue to execute correctly once the handler has returned.
>
>If you are looking for other book references check most assembler language references, a device driver book would probably help as well. I've written lots of interrupt handlers over the years. In most assembly language implementations you'll see code like this pseudo code:
>
>

>push AllRegisters
>... handler code goes here
>pop AllRegisters
>return
>

>
>This is because the CPU registers are a global resource and they MUST be saved before the handler does anything and restored before control is handed back to the code that was executing prior to the interrupt. If you don't do this you will most certainly crash the program.
>
>Likewise in VFP if you have any sort of ON handler or timer they must be written in a manner that will not cause the interrupted code to fail once the handler returns.

OK. For the sake of argument I'm going to weigh in on Peter's side :-)

>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