| Defining a callback that respects timers? [message #91918] |
Tue, 15 September 2015 09:21  |
dg86
Messages: 118
Registered: September 2012
|
Senior Member |
|
|
Dear Folks,
I am using IDL's timer() object to update images at regular intervals.
My program also processes user interactions, and therefore makes
use of callbacks. Starting with IDL 8.4, these callbacks block the
timer, and therefore mess up my regular intervals.
Is there a clever way to write a widget callback that somehow
checks to see if a specified timer is overdue to fire?
All the best,
David
|
|
|
|
|
|
| Re: Defining a callback that respects timers? [message #91928 is a reply to message #91926] |
Wed, 16 September 2015 05:46  |
dg86
Messages: 118
Registered: September 2012
|
Senior Member |
|
|
On Wednesday, September 16, 2015 at 5:46:31 AM UTC-4, superchromix wrote:
> I don't know the answer to this question, but I am very interested in the solution, if one exists.
>
> I also write user interfaces which need to periodically update, while another process (e.g. data analysis) is ongoing.
>
> Mark
One possibility might be to create a superclass of the timer object that stores its anticipated firing time as a property that can be polled with GetProperty. Any widget callback that might block the timer then could check to see if it's time to fire and, if necessary, could (1) cancel the timer, and (2) call the timer's callback.
I could imaging storing the deadline time as part of the userdata in the timer.set()
method.
Here's the catch: Timer() is defined as a set of built-in static methods (no source code,
I believe). So, I also don't see how to implement my own static Timer method to inspect the userdata.
It would be _REALLY_ nice to be able to set a timer that preempts widget callbacks
(pre-8.4 behavior), perhaps as an option to the Timer.Set() method.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
