Not one of my timers on Windows ever fires.
Yet, if I take the code for any of them and isolate it identically to a sample project, it works fine. I’ve got a big beasty of an app with timers embedded in windows and dynamically created (and properly stored for reference.)
Everything works fine in 2018r1 and before.
Works fine MacOS 2018r1.1
Actually, the timers do start firing when I commence exiting the app. Maybe something in the window blocking all timers?
Anyone have any clues? I’m running out of ideas…
This would be surprising. The IDE wouldn’t work if timers didn’t work.
Any possibility of timers getting discarded during the exit clean up? Even unintentionally, like belonging to a window closed before firing it?
It’s very surprising. Half my app doesn’t work. What could block a timer?
Well, some timers probably do get stopped or the property set to nil on CancelClose cleanup. Not sure how this would cause them to start working…
Its very odd that its working on previous versions in Windows. Looking through the release notes for 2018r1.1 didn’t show anything obvious. The only things I can think of are:
- The timers are being started inside a #IF XojoVersion which is causing them not to fire on the latest build.
- The only reason timers wouldn’t fire would be if there were too many of them, timers are a finite resource in windows and you can run out of them, but we’re talking large numbers here, like 32’000+ but if you had a run away bit of code that was constantly creating them, this could happen. However it wouldn’t explain why it works in previous versions, so I doubt its this issue.
- Try a reboot (see numbers 2)
Are you compiling in 32 or 64bit, have you tried simply switching to the other and see if the problem goes away?
Appreciate the suggestions Julian!
It seems to be related to listbox drawing and/or the celltag property. If I remove updating the celltag, the timers fire. Investigating further.
Very odd!
I can dynamically cause the timers to fire or fail at runtime by removing data from the listbox. Seems to be something to do with custom celltextpaint or background paint…
That’s an interesting one, are you able to replicate it in a simple test project?
I’m trying to isolate. Tricky bastard. Like hunting a mutating virus. 
Just two more shots in the dark:
Are you .Invalidate-ing or .Refresh-ing this Listbox in some places/situations (that could interfere with the paint-events)? If so: what happens with .Invalidate/.Refresh commented out?
Are you drawing somewhere outside of a PaintEvent directly to e.g. Window.Graphics or aControl.Graphics? I’ve seen very weird effects in the past with that.
@ 2018r1.1
In my case, it seems like the timer never got a chance to trigger my action handler, because the paint event was being called too often in a loop.
@Stephen Dodd comment out all the places you call Invalidate and/or Refresh and see if your timers work.
Question/thought:
That being said, are those actions called sent to some queue? It the queue a lower priority(compared to a paint event)? If the timer is stopped before said queue can run all the actions in the queue are they just removed from the queue or do they get to run their course when available? Is my thought even correct?
EUREKA!
You ever have that moment when you’ve been cursing the compiler for making you do this unnecessary debugging and it turns out that it’s your own darn fault!
In the Listbox.CellTextPaint event I was updating the contents of a listbox cell. Yes, I know. As a consequence, on Windows it was quietly infinite looping updating the cell and then painting it and then updating… It didn’t seem to affect the rest of the app but it sure screwed over the poor timers.
Thanks to everyone for their suggestions!