Timer stops after a couple of hours

I have the next strange phenominum:
In my Desktop application I have 3 timers:

1st. lets the application download and analyze files and stores the extracted info in a file
2nd. only function of this timer is to display the time in 4 offsets; GMT, NL time, US-time and Hong Kong time
3rd. shows new received events in a label every 10 seconds, over and over (looping)

Timers 1 and 3 are running without problems from start till I stop the application.
Timer 2 stops after a couple of hours.

I did put a debug stop in the code when the timer stopped running and… it never stopped there, because de code was not executed anymore. So, my conclusion is that the timer was indeed stopped or disabled.

I added some code in Timer-3 to check the status of timer 2 and if it found the timer off, it should make the timer run again. When it found the timer disabled, it would enable the timer again.

[i] if DTS_World.DTS_Timer.Enabled = False then
DTS_World.DTS_timer.Enabled = True
end if

If DTS_World.DTS_timer.Mode= DTS_World.DTS_Timer.ModeOff then
DTS_World.DTS_Timer.Mode =DTS_World.DTS_Timer.ModeMultiple
End if[/i]

I did put debug stops between the if … end if statements, but the program never stopped there, so the conditions that timer-2 was ModeOff or disabled were never met.

Nowhere in the complete code is somewhere written that the timer should stop after a couple of hours. Sometimes after 1 hour, most of the times after 2-3 hours that the program was running.

Odd is that the other 2 timers keeps on running from the start till the stop.

I am searching for the cause for about a month now, it suddenly started to do this, but I was till now not able to find the cause of this.

Does anyone know what could cause this? I really have no clue.

Please post the code in the Action event of Timer 2.

Here is the code of timer-2:

Dim d as new Date
Dim Time as string
Dim Dat as string
Dim CR as string = Chr(13)+Chr(10)
Dim WeekDays as string = “SunMonTueWedThuFriSat”

Time = Format(d.Second, “00”)
GMTSecond.Text = Time

d.GMTOffset=0
Time=Format(d.Hour, “00”) + “:” + Format(d.Minute, “00”)
Dat = Mid(WeekDays,(d.DayOfWeek*3 )-2,3)
GMTDate.text = Dat +CR + d.ShortDate
TimeGMT.text =Time

d.GMTOffset=1
Dat = Mid(WeekDays,(d.DayOfWeek*3 )-2,3)
GMTDate1.text = Dat +CR + d.ShortDate
Time=Format(d.Hour, “00”) + “:” + Format(d.Minute, “00”)
TimeGMT_NL.Text =Time

d.GMTOffset=-5
Dat = Mid(WeekDays,(d.DayOfWeek*3 )-2,3)
GMTDate2.text = Dat +CR + d.ShortDate
Time=Format(d.Hour, “00”) + “:” + Format(d.Minute, “00”)
TimeGMT_US.Text=Time

d.GMTOffset=8
Dat = Mid(WeekDays,(d.DayOfWeek*3 )-2,3)
GMTDate3.text = Dat +CR + d.ShortDate
Time=Format(d.Hour, “00”) + “:” + Format(d.Minute, “00”)
TimeGMT_HK.Text=Time

Check it’s Period, maybe it’s 2147483648.

Why do I have to check it’s period? The period is set in the object on 1000Ms, which is normal for a clock.
When I display all variables used every second in a text windows, I see nothing odd. All behave like it is expected to behave and the period is displayed all the time on 1000Ms. I do not mess around with the period too. As you can see above, I do not use any integer else, so what should make me reach the max. integers allowed?

Piece of the output now displayed in a log window showing all variable values used in this timer.action:

19:38:11
Sat
2016-03-12
1000
19:38:10
Sat
2016-03-12
1000
19:38:09
Sat
2016-03-12
1000
19:38:08
.
.
.
Sat
2016-03-12
1000
19:38:04
Sat
2016-03-12
1000
19:38:03

i have no clue why the timer stops. I will write down the start time and see what the stop time is, maybe I can calculate from there what might be the cause.

It still stays odd that the other 2 timers keeps on running. They did run the whole night, more then 12 hours and without any interruption or what. All data was received and processed and displayed. Ony my clock stopper :-s

“How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?” – Sherlock Holmes

As there are no clues about what is going on, you want to check every reason why your timer could be stopping. Some of these items have to be verified After the timer has stopped.

  • Is it enabled ? The control, not the mode (as in Timer1.enabled = false)
  • Is the mode right ?
  • Is the period right (does not cost much checking, does it ?)
  • Are there any references in the program that can change these (do a search)

At first glance, your code does not contain anything that seem able to break the execution or trigger a silent error.

Remote possibility but hey, before blaming the ghost, check if the control is not corrupted :

  • set the faulty timer to off
  • drag a new timer to the window
  • Add an Action event
  • Copy the code into it

If none of that works, go to church and light a candle to Saint Isidore of Seville…

I’m sorry, did not meant to make you upset…I will sort it out

I am not upset. The very basic of debugging is to examine everything, until you find what caused the error. Often enough, it is simple. Sometimes, you need to be more thorough.

Here, you are in luck. The reasons why a timer may no longer fire seem to be limited.

I started this thread that I am already strugling a month with this. And to be honest I did all what was proposed already, except the replacement of the Timer object. that was my next move, but I thought maybe it is a known behavior and a person more experienced with Xojo then me might saw this before.

I am running the application still with the debug lines in it and as soon as it will stop again and the debug output does not show something odd I will do my last option, which you also proposed: deleting the current timer and create a new one and paste the code in it. Maybe something went wrong inside the object, because I copy/paste the application time after time to be able to develop the app at work and at home.

Thank you all for your input and suggestions.

[quote=252847:@Michel Bujardet]

Here, you are in luck. The reasons why a timer may no longer fire seem to be limited.[/quote]

Michel, can you explain above phrase for me? Do you mean that timers cannot execute code till they are stopped? Is there a max for defined? Is there a way to get around it?

My tool just has to go around the clock an execute every 2 minutes a code to get information from the Internet and process it. If it stops doing this after a 4/5 hour run, this is not convenient, because information will be missed and that makes teh application unreliable.

For your information, I debugged all code concerning the timer again and nowhere in the code there is something which would stop the timer. I deleted the timer and replaced it for a new one, but still after a certain amount of time the timer stops. I have to stop and start the application to get again a running timer. Even after compiling the code and running the .exe the timer stops after a certain amount of time.

There I am writing more applications running on a timer I wander why this limitation would be done. Limitation I guess looking at the last phrase of your last comment. Can you tell me what other reasons there are to stop a timer besides changing the mode or disable the timer

Hum. Have you tried replacing that timer as I describe above ?

In my experience, Xojo multiple timers work fine over large periods of time. For instance, I use a method that many people have adopted in my Web apps to check if the cgi is still here every 5 minutes, and if not, quit the program. Web apps can be online months at a time, and it works (literally) like clockworks.

My phrase was just meant as an encouragement not to overlook anything, but that indeed, there are limited reasons why a timer may stop.

For all I know, I tried to honestly list the potential causes for your timer to stop.

If none of these causes apply, then the next step is to create a small test project with only one timer with the same period, with code similar to what is used in your project, and run it for long enough to see if the issue happens.

If the test program exhibits the same issue, then you can safely report the bug.

But I suspect it will work just fine for days and months in a raw. If that was the case, something else is happening in your code that disables the timer. And I have got no idea what it could be at this point. Probably something in your code generating a silent error that disables the timer, maybe a leak, whatever.

BTW a couple more questions :

  • Which platform ? Windows, Mac, Linux ?
  • Where is the timer ? A window, a containerControl, App, Module ?

Windows and container controls can get out of scope. A probably better place would be App, but you will have to use Addhandler to access the Action event.

On Mac with App Nap and on PC with the Power Settings the app may become frozen by the system.

I referred to Sherlock Holmes : you start with hypothesis that you follow as leads until you find the culprit. Sometimes it is easy, sometimes, it takes longer. Good luck.

What happens if something goes wrong there? No connection, corrupt data, etc?

[quote=252853:@Rob Valk]I started this thread that I am already strugling a month with this. And to be honest I did all what was proposed already, except the replacement of the Timer object. that was my next move, but I thought maybe it is a known behavior and a person more experienced with Xojo then me might saw this before.

I am running the application still with the debug lines in it and as soon as it will stop again and the debug output does not show something odd I will do my last option, which you also proposed: deleting the current timer and create a new one and paste the code in it. Maybe something went wrong inside the object, because I copy/paste the application time after time to be able to develop the app at work and at home.
[/quote]

In answer to your known behavior question the answer is no, a timer should be able to run indefinitely. I have a 1-second heartbeat timer in an app that runs for 18 months between updates on some users machines.

Will the app do it running in debug mode from the IDE? You can add a button to the window that just has a single line of “break” in it to bump you into the debugger. You may be able to get to the debugger by just pressing pause in the IDE but I’m not sure how that works if code isn’t actually executing or not, it may be different. Then you should be able to view all your global variables which will include the windows and you then look into them and find the timer controls and actually look at their properties during the error. That will tell you if they are getting set to mode 0 or if the period is getting reset to something unhelpful somewhere.

Are these timers all controls dragged into a window? Or are you creating them as separate classes? I know that if you remove all your references to a timer class that is not a control it will be cleaned up and removed and stop firing, but that shouldn’t happen to one that is dragged into a window as a control.

My only long term experience with timers as I mentioned above were as separate subclasses that I maintained in global variables. So that is something to try if it’s the placing them in a window that is causing the trouble. I’m not aware of any such bug and I think it would be a serious issue with many reports if timers stopped firing on windows, still it’s something to try.

Ok, that is just what I also thought, timers should run indefinately.

Michel, my app. is a windows app., I will probably delete the current code (I will save it somewhere else) and have other code there to execute, just for test purposes.

The timer is in the main window and so I did not expect any problem with it. Strange is that I have also timers running in contianer controls which are running for the whole day and do not stop, while the timer I am talking about already was stopped.

I will continue to investigate and debug this issue in my application and if I find out what it is, than I will publish it here. Just as a lesson learnt for beginners like me. :slight_smile:

Thank you all again for the responses

Still, have you tried to put a new timer on your window, and move the Action event handler to it ?

Yes Michel, I did delete the old timer and put a new one on it and paste the code in it. The timer did stop after a couple of hours. I replaced the timer again by a new one and entered a simple control code in it to see if it will keep on running.

For all interrested in this thread:

The timer problem had 2 faces:

  1. A text area used as log was filling so much that no time was found anymore to run the timer, thanks to Marco Hof for explaning this. This has been fixed by using the log differently
  2. A bug was found which might also played a part in Xojo 2015 r.4 to stop the timer, but currently the project is running fine for >12 hours without stopping timers, so I still guess the issue under point 1 was the most important culprit for me.

However, under Xojo 2016 r.1 I had excessive timer issues for which I openend a case with Xojo. The cases were describing the same bug found under case#Case#43169

QUOTE
Remote debugging an app from Mac OSX 10.11.3 to Windows 10. Appears that a function that resets a timer by setting mode=1 is called several thousand times in rapid succession and caused the fault. Xojo 2015r4.1 fails silently at the same point and the timer never fires.
UNQUOTE

My cases are closed as dups

Hello,
by the way, in terms of CPU usage, how much expensive is a timer (period = 300) firing for days and days? I ask because I always felt that CPU usage would increase. I’d be happy to be told that I’m wrong.
Timer action:
If Keyboard.AsyncKeyDown(123) then
//do something with the left arrow key
end if

A timer consumes almost no CPU. Contrary to tight loops.

Thank you, Michel. Happy to have my doubt dispelled.