Dynamic access to the Xojo.core.timer seems to be hampered by not being able to set the mode because the values off, single, multiple, are part of the Modes enumeration. Calling:
leads to failure, so using “REALSetPropValueInteger” is a no-no. If it is true that Xojo.core.timer.tolerance will alleviate the windows limitation of 15 ms then the core timer is preferred. Note that calling:
I would expect they are integers: drag a timer on the window and set its super to Xojo.core.timer. The mode is an integer. Whether it is an enumeration or a constant, local reference says modes is an enumeration, it should and can be casted to an integer.
Dang, if one cannot access this from a plugin …
The plugin uses XojoScript to load dynamically 78 bevel buttons on a window. XojoScript runs in a thread and every time a bevel button needs to be modified the thread is suspended and a single-shot timer takes care of the update. If a classic timer is used it takes 20 ms to fire the timer on windows; on the Mac it takes 2 ms. If the plugin uses the BackgroundTaskProc callback, it still takes 20 ms on Windows, but on the Mac there is a significant improvement (about 0.4 ms). On the Mac, it therefore takes about a second to have the window loaded with all the buttons.
On windows we tried to call the timeGetDevCaps to get a resolution of 1 ms:
The result of this is that we do get the wTimerRes to be 1 ms. The result is a slight improvement, i.e., it now takes 15 ms to fire the backgroundtaskproc or the classic timer. Given the Xojo.core.timer.tolerance, we were wondering if the modern timer supports 1 ms resolution. But given we cannot set the mode, it seems we need to create a timer from scratch.
Any comments that would help us to move forward? It is really awkward to wait 30 seconds before the window is populated. It is in essence a real show-stopper.