Life of a webTimer

hi, I would like to understand the life cycle of the activity of a single mode web timer.
Let me explain, I have a webapp, in one of its web pages a button sets the webtime to single mode and enables it, inside the webTimer calls a function that processes data and updates a db. If the thing is long, the user could close the page … at that point, what is foreseen in the code of the webTimer continues to be executed? and the code present in the function called by the webTime continues to be executed until the end?

did you set the timer mode to “off” in the inspector at design-time?

the webTime is set by default with mode = 0. The button sets the webTimer mode to 1, then in the webTimer code a function is called after which, again in the webtime code, the webtimer mode is set back to zero

can you share us your code or a small test project?

The thing with webtimers is, that they live on the webpage itself. It is a frontend control, which communicates with the server. There’s a lot going on which can fail, due to bad app design, bugs, internetspeed and lag.

I always prefer to use a Timer (not Webtimer). This lives on the server.

You can use it so:

  • make a property thisServerTimer on your weblayout
  • instantiate a servertimer in the open-event of you webpage with:
self.thisServerTimer = new Timer 
addhandler thisServerTimer.Action, AddressOf thisServerTimer_Action 
thisServerTimer.Period = 10000 
thisServerTimer.Mode = Timer.ModeSingle

this is a completely different workflow, as both timers, webtimer and timer, has nothing to do with each other from their implementation point of view. But it works like a sharm.

Have also followed the approach that Lars recommended for several situations.

Just a reminder that Server Side Timers (as opposed to WebTimers) need to use a WebSessionContext to access the Session.

If the WebTimer is set to Browser and the browser gets closed, the timer will not fire because the trigger was in the page on the browser.

1 Like