Dunno. For example, if you want an interval of each 1 second and the timer has processing time between .1 to .5 seconds, then in reality disabling+enabling would lead to intervals 1.1 to 1.5, instead of 1. Because the interval is reset on each case of enabling.

Another case is that there are two timers. If an exception occurs in timer1.timer() even before the IF, then your advise would indeed prevent the stack-problem. However, the second timer would continue even during the exception handling. This is BTW a situation that I dislike. Perhaps a procedure within the exception handler should temporarilly disable all timers.

>No, it's not the speed of the check, it's the time it takes for the whole event to run. Edge cases can make it take longer than expected, or your handler may hit an unexpected error. You don't want your timer to fire again under those circumstances, you want your system to be as deterministic as possible.
>
>Always disable at the top - no exceptions.
>
>>Thanks Al, for this elaboration. Your remark about always disabling is true in general, but if the IF merely tests a logical or other fast enough check, then it's better not to disable, IMHO.
>>
>>>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?