Dynamic access to the Xojo.core.timer modes enumeration

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:

void Timer_SetMode(REALobject self, RBInteger value)
{
	if (REALSetPropValueInteger((REALobject)self, "Mode", value)) return;
	MSG(DYNAMIC ACCESS FAILURE: Timer_SetMode)
}

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:

void Timer_SetPeriod(REALobject self, RBInteger value)
{
	if (REALSetPropValueInteger((REALobject)self, "Period", value)) return;
	MSG(DYNAMIC ACCESS FAILURE: Timer_SetPeriod)
}

does not fail, indicating we can get an instance of the core timer.

The three values for Timer.Modes are labelled as constants in the docs, not as enumeration. Don’t know what they are internally.

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 …

Xojo.Core.Timer (new framework)
http://developer.xojo.com/xojo-core-timer$Modes

Not classic timer
http://developer.xojo.com/timer$Mode

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:


#ifdef WIN32

#define TARGET_RESOLUTION 1         // 1-millisecond target resolution

TIMECAPS tc;
UINT     wTimerRes;
bool noError = true;
#endif

#ifdef WIN32
        if (REALinRuntime()) {
            if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR)
            {
                // Error; application can't continue.
                noError = false;
                ScriptPluginLog((char*)"Could not get timer target resolution");
            } else {
                wTimerRes = min(max(tc.wPeriodMin, TARGET_RESOLUTION), tc.wPeriodMax);
                timeBeginPeriod(wTimerRes);
                ScriptPluginLog((char*)"Got the timer target resolution with resolution %d", wTimerRes);
            }
        }
#endif

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.