I need (amongst other things) a png file to reload after one minute.
What would be the best way to time and trigger this event? I have
thought of using the threading module's Timer class or perhaps Pygame's
Time section? Also it should be able to time in the background while
the user can perform other tasks within the program.
···
--
Regards,
Wayne Koorts www.koorts.com
wkoorts@mweb.co.za
I need (amongst other things) a png file to reload after one minute. What would be the best way to time and trigger this event? I have
thought of using the threading module's Timer class or perhaps Pygame's
Time section? Also it should be able to time in the background while
the user can perform other tasks within the program.
Use a wxTimer.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I need (amongst other things) a png file to reload after one minute.
What would be the best way to time and trigger this event?
Use a wxTimer. See the demo under Process and Events. There is also a
wxPyTimer, which has a slighter easier to use interface. It is
instantiated like this:
self.Timer = wxPyTimer(Callback)
Where Callback is the function you want to call when the time goes off.
The rest of the methods are the same as the wxTimer, I think.
I have
thought of using the threading module's Timer class
That will work, but not as we4ll, and it's a lot messier.
Also it should be able to time in the background while
the user can perform other tasks within the program.
wxPYTimer will do this nicely.
Take a look at throbber.py in the demo. It used to use thread.timer, but
it was going to get re-worked to use wxTimer, I'm not sure which version
is in the current demo, but it's worth looking at, in any case.
-Chris
-- --
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Ah thanks guys, Chris: Is the wxPyTimer a standard wxPython object?
···
--
Regards,
Wayne Koorts
www.koorts.com
wkoorts@mweb.co.za
On Wed, 2003-04-30 at 21:32, Chris Barker wrote:
Wayne Koorts wrote:
> I need (amongst other things) a png file to reload after one minute.
> What would be the best way to time and trigger this event?
Use a wxTimer. See the demo under Process and Events. There is also a
wxPyTimer, which has a slighter easier to use interface. It is
instantiated like this:
self.Timer = wxPyTimer(Callback)
Where Callback is the function you want to call when the time goes off.
The rest of the methods are the same as the wxTimer, I think.
> I have
> thought of using the threading module's Timer class
That will work, but not as we4ll, and it's a lot messier.
> Also it should be able to time in the background while
> the user can perform other tasks within the program.
wxPYTimer will do this nicely.
Take a look at throbber.py in the demo. It used to use thread.timer, but
it was going to get re-worked to use wxTimer, I'm not sure which version
is in the current demo, but it's worth looking at, in any case.
-Chris
-- --
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
Ah thanks guys, Chris: Is the wxPyTimer a standard wxPython object?
Actually, wxPyTimer is just an implementation detail for wxTimer that dates back to when I didn't have good plumbing in place for automagically doing Python callbacks from C++ virtual functions. Since people were using it directly I didn't remove it when I did have the plumbing.
IMHO, the best way to use a timer these days is to have it send an event to one of your windows, like this:
Understood Thanks very much for the help. Appreciated
Wayne
···
On Wed, 2003-04-30 at 21:51, Robin Dunn wrote:
Wayne Koorts wrote:
> Ah thanks guys, Chris: Is the wxPyTimer a standard wxPython object?
>
Actually, wxPyTimer is just an implementation detail for wxTimer that
dates back to when I didn't have good plumbing in place for
automagically doing Python callbacks from C++ virtual functions. Since
people were using it directly I didn't remove it when I did have the
plumbing.
IMHO, the best way to use a timer these days is to have it send an event
to one of your windows, like this:
Read up on wxTimer. In your timer handler, you can spawn off a regular
Python thread that points to some method to reload the PNG or do any
kind of work you want. Then it can inform the main GUI thread with
wxCallAfter(obj.graphicIsReady, image).
Finally, be wary of using wxBitmap in other threads. At least on
X-Windows that will fail. wxImage is safe, though.
HTH,
···
On Wednesday 30 April 2003 11:47 am, Wayne Koorts wrote:
Hi,
I need (amongst other things) a png file to reload after one minute.
What would be the best way to time and trigger this event? I have
thought of using the threading module's Timer class or perhaps
Pygame's Time section? Also it should be able to time in the
background while the user can perform other tasks within the program.
In the same vein as using wxCallAfter(), maybe we could make this:
wxCallDelay(1000, self.fooBar, args)
Then you simply call it again in self.fooBar if you want it.
The implementation would refrain from making the call if self was a
PyDeadObject. Assuming "self.fooBar" is stored in a variable called
"callback", the check would look like this:
if callback and getattr(callback, 'im_self', True):
callback(*posArgs, **kwArgs)
The "im_self" bit lets you check up on the object of a bound method.
I'm not sure how the timing bit would be handled in the bowels of
wxPython/wxWindows. Robin might have an idea...
Reactions?
···
On Wednesday 30 April 2003 12:51 pm, Robin Dunn wrote:
IMHO, the best way to use a timer these days is to have it send an
event to one of your windows, like this:
In the same vein as using wxCallAfter(), maybe we could make this:
wxCallDelay(1000, self.fooBar, args)
Then you simply call it again in self.fooBar if you want it.
The implementation would refrain from making the call if self was a PyDeadObject. Assuming "self.fooBar" is stored in a variable called "callback", the check would look like this:
if callback and getattr(callback, 'im_self', True):
callback(*posArgs, **kwArgs)
The "im_self" bit lets you check up on the object of a bound method.
But you would want to be able to use any callable object here, not just bound methods...
I'm not sure how the timing bit would be handled in the bowels of wxPython/wxWindows. Robin might have an idea...
Reactions?
I think it is a good idea, but it should provide a way to cancel delayed calls before they timeout, perhaps wxCallDelay could return a handle that can be used to cancel it later?
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Chuck Esterbrook wrote:
> In the same vein as using wxCallAfter(), maybe we could make this:
>
> wxCallDelay(1000, self.fooBar, args)
>
> Then you simply call it again in self.fooBar if you want it.
>
> The implementation would refrain from making the call if self was a
> PyDeadObject. Assuming "self.fooBar" is stored in a variable called
> "callback", the check would look like this:
>
> if callback and getattr(callback, 'im_self', True):
> callback(*posArgs, **kwArgs)
>
> The "im_self" bit lets you check up on the object of a bound
> method.
But you would want to be able to use any callable object here, not
just bound methods...
Right. That's why I used getattr() instead of accessing the attribute
itself. And the "if callback" lets whatever it is participate first.
> I'm not sure how the timing bit would be handled in the bowels of
> wxPython/wxWindows. Robin might have an idea...
>
>
> Reactions?
I think it is a good idea, but it should provide a way to cancel
delayed calls before they timeout, perhaps wxCallDelay could return a
handle that can be used to cancel it later?
Seems reasonable. I would say "object" instead of "handle" and give it a
method "cancel".
futureCall.HasRun() - Returns bool indicating if this object has run yet
futureCall.Result() - The return value of the callback function. I'm not
sure what the best behavior if the function has not
yet run. Perhaps raise an exception if it hasn't run.
A couple pennies from me,
Mark Peters
···
On Wednesday 30 April 2003 08:21 pm, Robin Dunn wrote:
Chuck Esterbrook wrote:
> In the same vein as using wxCallAfter(), maybe we could make this:
>
> wxCallDelay(1000, self.fooBar, args)
>
> Then you simply call it again in self.fooBar if you want it.
I think it is a good idea, but it should provide a way to cancel
delayed calls before they timeout, perhaps wxCallDelay could return a
handle that can be used to cancel it later?
Seems reasonable. I would say "object" instead of "handle" and give it a
method "cancel".
I'm still not sure what the internals are. Do we just set up a new timer on each call?
I think this sounds like a good idea.
A few other methods come to mind:
futureCall.HasRun() - Returns bool indicating if this object has run yet
futureCall.Result() - The return value of the callback function. I'm not
sure what the best behavior if the function has not
yet run. Perhaps raise an exception if it hasn't run.
I changed Notify() to increment the runCount you created in __init__ and
to not pass "self" to the callable:
def Notify(self):
if self.callable and getattr(self.callable, 'im_self', True):
self.runCount += 1
self.result = self.callable(*self.args, **self.kwargs)
self.hasRun = True
I did some light testing and it seems to work fine.
Thanks,
···
On Friday 02 May 2003 10:28 am, Robin Dunn wrote:
Mark Peters wrote:
>>Seems reasonable. I would say "object" instead of "handle" and give
>> it a method "cancel".
>>
>> futureCall = wxCallDelay(1000, self.foo, 14, s='x')
>>
>> futureCall.cancel()
>>
>>
>>I'm still not sure what the internals are. Do we just set up a new
>> timer on each call?
>
> I think this sounds like a good idea.
>
> A few other methods come to mind:
>
> futureCall.HasRun() - Returns bool indicating if this object has
> run yet
>
> futureCall.Result() - The return value of the callback function.
> I'm not sure what the best behavior if the function has not yet
> run. Perhaps raise an exception if it hasn't run.
>
> A couple pennies from me,
Is 0 a valid millis argument? If so, the method needs to be tweaked.
···
On Monday 05 May 2003 11:39 am, Robin Dunn wrote:
Chuck Esterbrook wrote:
>>Something like this perhaps? (See attached.)
>
> I changed Notify() to increment the runCount you created in
> __init__ and to not pass "self" to the callable:
Oops, thanks. Those were artifacts of trying different approaches.