Just my 2 cents:
I've used (non one-off) Timers in other GUI applications but not yet in
Dabo. They are very handy, if you have use for them.
If it weren't for the SEGFAULTs you mention, I think it makes sense to
expose wx.TIMER to dTimer.
On 02/03/2012 05:13 AM, Paul McNett wrote:
> {{{
> class DigitalClock:
> ...
> def afterInit(self):
> self.displayCurrentTime()
>
> def displayCurrentTime(self):
> self.txtHour.Value = ...
> ...
> dabo.ui.callAfterInterval(1000, self.displayCurrentTime)
> }}}
>
> ...without the complication of managing the timer.
>
> Paul
I think that the problem such an implementation is that it will be
subject to drift, which in most cases when you do need a timer makes it
less useful.
You could go the extra mile and account for the drift by computing
elapsed time, but even then you'd have to test against the timer
skipping a beat, in the case someone's code depends on a certain number
of beats in a time period.
Of course, those are general considerations and may not be relevant to
Dabo. Personally, I don't think they are.
I think the 7606 commit looks fine, but you may want to document the
drift potential, in case someone tries to depend on accuracy.
I may fire some tests tonight and see if I can confirm the drift, and
whether wx.TIMER does any better.
Nick Raptis
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/[email protected]
