I am facing a weird one. Everything has been working well. Complex UI, lots of controls,…
The number of controls being displayed at any one time increases with the amount of data being handled.
On Mac no issues. On Windows, everything works well up to a certain size of data set. Above a certain size, things go wrong.
Essentially, all Timer controls stop working.
Plus, in the debugger, I also get weird ‘Ignore’/‘Report’ dialog. When these occur the code is always pointing at an issue with a Timer control: the IDE stops on a line that typically will say ‘someTimer.Mode = something’.
After a bit of research I found that on Windows system timers are a limited resource, and my suspicion was that I was a bit too liberal and used too many of them, as Xojo timers probably map onto Windows system timers.
I had originally attached a timer for debouncing to each a whole range of composite controls, and I was using 100s if not 1000s of timers like there was no tomorrow.
As I don’t need accurate timing (it’s mostly debouncing stuff), I cleaned things up, and reduced my ‘timer footprint’ to just one single Xojo Timer.
It gets created on startup, starts ticking and replaces the 1000s of timers. I have this timer on ModeMultiple, and have it fire regularly, and I do all my debouncing with just the one timer.
The strange thing is: the issue did not disappear. I am still getting ‘Ignore’/‘Report’ dialogs when I use statements like ‘myOnlyTimer.Mode = 2’.
The things I do know:
- It is Windows-only
- It’s related to the size of the task. Beyond a certain size things start breaking
- It is related to timers
at a certain point, any and all timers stop working. In my latest test, my one and only timer stops working.
So, my theory is that something else, hidden inside, might be leaking timers.
Anyone experience something like that?