On Timers

[paulmansour]

Hi all.

Up until recently, I have only used "countdown" timers - that is timers that are activated only when a user does something, and that deactivate themselves immediately upon firing. These are fairly easy to deal with, and they don't get in the way much.

Now I have a need for a permanent "polling" timer for keeping a GUI up to date, and have the problem of the timer going off far more often than I want it to. For example, it appears that the onTimer event stacks up on the queue when menus are visible. If the user opens a drop down menu, and does not make a selection but pauses there for a while, then upon cancelling the menu, the timer callback may then fire a bunch of times in immediate succession. I assume there are other cases where this may happen (though a modal []DQ does not appear to be one of those).

This problem can be handled by having the timer callback function track the time it last fired, and exiting early if the actual interval is much shorter than the specified interal, which is in fact what I have done.

Another problem is when debugging, you have the timer going off repeatedly which can be annoying. Other than explicitly de-activating the timer or timers when debugging I can't think of any way to avoid this.

Yet another issue is that when closing the parent form of a timer whose job it is to keep the form up-to-date, you can get a value error situation ... I suppose the close callback can see if the timer callback is running and wait for it to finish somehow...

Anyway, my question is for those of you who are experienced with timers, any thoughts or pointers or tips or tricks to share? I'm sure I'm going to run into more issues that I have not thought of.

[kai]

I encountered exactly the same problems. I got around the first two problems by doing something like this:

Code: Select all

OnTimer←{
  _←⎕EX ⍵
  ...
   CreateTimer ⍬
}

Meaning that the first thing the callback is doing is killing the timer object and therefore get rid of any potential backlog of timer events. The last thing is re-creating the timer. When debugging you can jump over the last line in order to get rid of the Timer.

When the Timer is needed during the debug session every now and then a global variable is more appropriate.

I found no other way to get around the VALUE ERROR than trapping it: even checking with ⎕NC first can result in a spurious VALUE ERROR.

[paulmansour]

Kai,

Thanks. I'll try that, but I'll be pleasantly surprised if that works, as the problem is that callbacks are stacking up. For example I tried de-activating and re-activating and this does not help, so I can't see how deleting and recreating will help, but I'm going to give it a shot now.

Paul

[paulmansour]

Well, I AM surprised. Deleting and recreating works. It never occured to me to try that after deactivating and reactivating failed to do the trick.

Thanks!

[Phil Last]

Only a guess but if there are already muliple events stacked up for a particular timer and that is deactivated temporarily it will merely delay their execution. If it is expunged they will have no-where to go. The replacement won't pick them up because it's not the same ref.

[kai]

Sounds good but does not fit to the VALUE ERRORs...