I’ve already logged/traced the code execution using DebugLog, and it’s all working as expected except that the timer doesn’t reset. The Reset method is called at ≈100ms intervals, but the timer still times out after its nominal period, which is > 100ms and therefore should never happen. The code is really simple.
What I could do is make my own Timer class using microseconds - that would probably work.
Someone suggested nil-ling the timer after the first firing. Have you tried that? I’d be curious to see if the Destructor fires.
What happens if you rather set the enabled property to false? (I know you already mentioned you tried that, but the outcome wasn’t mentioned).
With setting the enabled property, if you watch it from inside the timer’s action/run event, I can see only two answers, which you’d figure out quite easily:
1: the enabled property is indeed false, so the fact the timer executes when disabled is an odd case. We should be able to reproduce that.
2: the enabled property has become true again. In such case, I’d subclass the timer (if not already done) and move any code that changes the timer’s enabled/mode in a new method in the subclass. Then you can monitor exactly what changes your timer in a centralised place.
The problem is not that the timer can’t be disabled, the problem is that the timer cannot be reset.
A timer is just a register in the class that gets incremented or decremented at regular (small) intervals. When the register increments to the period value or decrements from the period value to 0, the timer’s Action event is called.
When the Reset method is called, or the timer is enabled after being disabled, or the timer’s RunMode is changed, the register is supposed to be initialized - to 0 for an incrementing timer or to the period value for a decrementing timer.
In a watchdog application like mine, the timer must be running (enabled) all the time, but gets reset periodically at intervals smaller than its period so it should never fire. This graph shows a timer being reset to 0 at intervals, and the “Upper Limit” (ignore the “Lower Limit”) could be its period value where the Action event is called:
I haven’t. Seems like it would probably work, but I’d have to not only reinstantiate it, but remove and add its handler. This feels uglier to me than putting the property in a module, but at least it would maintain encapsulation. I’ll give it a try when I have some time.
That snippet of documentation suggests that doing
mytimer.RunMode=myTimer.RunMode
…is the same as
myTimer.Reset
Honestly I didn’t even know that Reset was a method - in your situation I’ve always flipped the RunMode from Off and back to Single. Perhaps this could be an easy fix.
That is correct. When things are working correctly, any of the following will reset a timer:
And I tried all of those things as mentioned in my OP 
May it be that your Project has been corrupted? Because such an issue with Xojo 2021r2.1 would certainly be known.
I’m not sure that that is a good assumption, as I imagine there are not all that many people using both R2021 and PhidgetsMBS. The issue may be specific to the fact that the malfunctioning timer is a property of a Phidgets subclass. This is supported by the fact that it works fine as soon as the property is moved out of the subclass.
This works:
This does not work:
The code is identical, no changes. Just move the property.
Hmmm.
Per MBS: “We wrap the C API from Phidgets library…”
Looking at the Phidgets Library, the Google AI provides this info:
The “Phidget Library” doesn’t have a built-in timer function. Instead, you can use the event-handling capabilities of the library to create your own timer. Phidgets are typically used with external devices that generate events, and you can use these events to trigger actions at set intervals.
I am wondering if there is conflict between the Xojo Timer Class and the underlying Phidgets library? Christian may be able to delve into this a little further. Based on your scheduling requirements (as opposed to your program’s scheduler), it may be best to stick with keeping the Timer in a separate module, since that is consistently working. Hoping for a swift resolution!
Phidget input devices themselves obviously have internal timers, because they deliver values at periodic intervals, but yeah, the MBS Phidget Library has no user-accessible timers.
I wonder, too. It’s weird, but seems to be the only thing that would fit the symptoms.
Right. I was thinking that if you disabled the timer, it would be sufficient. Then you could, for instance, use Timer.CallLater to reenable it (an over-complex way, I recognise, but since it’s about searching for a workaround…).
