Working with VFP timers has some similarities to interrupt service routines (ISRs) in systems programming. Developers who have not been exposed to them may not be aware of the issues involved, such as the possibility of stack exhaustion or infinite loop you encountered.

In general, for reliable operation you can't say that a timer event WON'T take a long time. A network connection could be congested, a disk could be almost full etc. So, as you point out the very first meaningful command in the timer event should be to disable it. That should NOT be contingent on whether you believe the operation should take a long time; it should always be disabled.

Then, assuming you want the timer to continue to operate after processing the event, re-enabling it should be the very last meaningful action in the event.

It's worth pointing out that in some versions of VFP, certain conditions would prevent VFP timers from firing at all e.g. having a menu expanded. I don't know if that's still the case with VFP9. Many years ago Bela Bodecs created an FLL to work around these issues: https://www.levelextreme.com/Home/ShowHeader?Activator=17&ID=9315

In some cases BINDEVENTS( ) may be a better option than using a timer.

>After almost 7 years I had the similar situation and was unsure about the functionality, searched here and rediscovered this thread. None of the replies made clear how ENABLED really relates to RESET and INTERVAL. So, here's my answer after having done a test.
>
>The basic principle for the timer's interval is NOT so much 'how long', but rather 'HOW OFTEN'. Suppose the interval is 1 second, then the timer() event will be visited 10 times in 10 seconds. Sure, if the code in the event takes less than 1 second, then it will be visited each second. HOWEVER, if the code in the Timer() event takes LONGER than 1 second, than a STACK will be used and ALL visits will be done AFTER the timer event finished.
>
>Think of the consequence. Suppose on the first visit the event takes 10 seconds, than immediately thereafter the 2nd till 10th visit take place. They were POSTPONED, NOT CANCELED.
>
>To prevent this overload (or even troublesome amount) of events, it is necessary to set ENABLED to FALSE at the TOP in the timer event and to set it to TRUE at the end. Or better, to set it to False at the top AFTER an IF that indicates that a time consuming action is about to occur. And accordingly set it to True just before the ENDIF.
>
>A trade-off of setting ENABLED to TRUE is that it works like a timer.RESET(). This is not documented, but it is nevertheless true. The consequence is that there's a fundamental difference between these ways of setting to true:
>

timer1.enabled = .T.

>

if not timer1.enabled
>    timer1.enabled = .T.
>endif

>
>
>
>
>>I have a container with a TIMER that has the INTERVAL set to 1 minute. It is ENABLED (or disabled) in the REFRESH of the container. That refresh is visited each 10 seconds.
>>
>>I noticed that the timer did no longer fire each minute if its ENABLED.property is explicitly set to True each 10 seconds.
>>
>>It does fire if I only set the ENABLED property if its new value differs from the current value.
>>
>>It seems as though the ENABLED property acts as some sort of RESET().
>>
>>Who can explain this? Or do I miss a clue?