I’m seeing something new in 2018r2 under Windows and not OSX.
I have an app originally built years ago in RealBasic for Windows and Macs that I’ve been improving and upgrading until today. My main form has perhaps 20 timers–one used as a status checking loop, others used to open or close windows after some delay, etc.
I’m finding in 2018r2 under Windows that the timers are not firing. Neither Single- nor Multiple-mode timers ever have their Action event triggered.
I’ve not yet found a way to isolate the problem into a sample app.
Some other details: My app opens by hiding its main window, and in a method of the main window opens then by timer on the main form hides a splash screen, unhides itself, then opens a Recent Readings window. Some other windows are opened and hidden in preparation of future events. In r2, the close-window timer for the splash screen never fires.
As perhaps a curiosity but maybe important: many of the timers have a TabPanelIndex parameter, a couple also an empty InitialParent parameter.
First thing would be to check all Paint events to make sure that you aren’t doing anything other than drawing. If you are calling Methods from inside your Paint events, also check those methods. Even doing something that is seemingly trivial like changing a label text colour inside a Paint event could cause issues.
What happens is that a Paint makes an alteration to something that causes that control to paint which again causes the thing to alter and the paint to trigger ad infinitum. This floods the event queue and causes issues with timers because they have no time to fire.
If you don’t get find anything obvious I’ll point to towards some tools that should narrow things down a little, let me know how it goes.
Is there something about Paint events in 2018r2 under Windows that would suddenly trigger this problem?
Thanks Derk. The timers in question are a couple of milliseconds and 5000, respectively, and are on windows that might be hidden but are not closed. ImplicitInstance is on.
Its happening because of the fixes put in place to correct the flicker/pop through issues in windows. The old system used to draw the controls the wrong way around, for example, changing a label that looked like it was on top of a canvas didn’t cause a refresh because it was in fact behind the canvas (in terms of windows handling things). Now things are the correct way around so changing a label in front of a canvas will also cause a paint of the canvas behind it in certain circumstances.
