>>>Reading this I got a better idea - if I'd want to restore them when I finish debugging, I wouldn't know which ones were active. So perhaps a better idea would be to set their intervals to some insanely large value, perhaps a megasecond up, and then when restoring just remove that megasecond... like this
>>>
>>>timer.interval = timer.interval + 1000000 && disable
>>>timer.interval = timer.interval % 1000000 && enable
>>>
>>>Of course, if the timer's code adjusts this.interval and that code somehow runs after this, well, see with the person who wrote it :).
>>
>>Personally I us Thor, in which I have created a keyboard shortcut , ctrL-D, to switch the debugger on and off. This works perfectly, and without doing any more trickery. I wonder if anyone can give me a good reason why they don't use Thor. It saves me hours every week.
>
>I use several things from Thor - and I can confirm that not only it saves time, but actually makes a few things possible which previously weren't. Debugger shortcut is not practical in my case, because most of the time I want a breakpoint at exactly the suspect location, not half a second before or after.
>
>The issue of timers while debugging is actually quite frustrating, when various screen candy comes with so many of them - toolbars using them to refresh, statusbar likewise, hover buttons having their own... and if you turn the debugger on, all that code executes visibly slower and you have to wait... but then it executes again because some of the timers are set to 100ms. It's a nightmare. So something like killtimers.prg is necessary, saves some nerves at times.

With the keyboard shortcut I can disable the debugger when I forgot to before running code, and vice versa, I can still add breakpoints which then will be or won't be respected. I have also been able to escape from endless loops in some cases, but not always.