when starting a timer owned by a window/dialog, which is repeatedly created/destroyed, the timer(s) bound to that window continue after destruction of that window
Also OnDestroy is never called.
And explicit self.timer.Destroy() somewhere also will not destroy the timer (=> needs explicit self.timer.Stop() somewhere)
Are these bugs? Or what is the right way for letting owned objects like timers join death of the owner window?
On Jul 29, 1:48 pm, Robert <kxrobe...@googlemail.com> wrote:
when starting a timer owned by a window/dialog, which is
repeatedly created/destroyed, the timer(s) bound to that window
continue after destruction of that window
Also OnDestroy is never called.
And explicit self.timer.Destroy() somewhere also will not destroy
the timer (=> needs explicit self.timer.Stop() somewhere)
Are these bugs? Or what is the right way for letting owned objects
like timers join death of the owner window?
I'm pretty sure you need to just use the Stop() method. That's what I
do when I close one of my applications. I catch the close event, and
then stop the timers that are running before I destroy the frame.
On Wed, Jul 29, 2009 at 1:48 PM, Robert<kxroberto@googlemail.com> wrote:
when starting a timer owned by a window/dialog, which is
repeatedly created/destroyed, the timer(s) bound to that window
continue after destruction of that window
Also OnDestroy is never called.
And explicit self.timer.Destroy() somewhere also will not destroy
the timer (=> needs explicit self.timer.Stop() somewhere)
Are these bugs? Or what is the right way for letting owned objects
like timers join death of the owner window?
def __del__(self):
if self.timer.IsRunning():
self.timer.Stop()
when starting a timer owned by a window/dialog, which is
repeatedly created/destroyed, the timer(s) bound to that window
continue after destruction of that window
Also OnDestroy is never called.
And explicit self.timer.Destroy() somewhere also will not destroy
the timer (=> needs explicit self.timer.Stop() somewhere)
Are these bugs? Or what is the right way for letting owned objects
like timers join death of the owner window?
def __del__(self):
if self.timer.IsRunning():
self.timer.Stop()
( the check wouldn't be necessary )
the dlg/wnd object is unfortunately (mostly) not dying so soon, and the timer continues. __del__ is very unreliable
···
On Wed, Jul 29, 2009 at 1:48 PM, Robert<kxroberto@googlemail.com> wrote:
when starting a timer owned by a window/dialog, which is
repeatedly created/destroyed, the timer(s) bound to that window
continue after destruction of that window
Also OnDestroy is never called.
And explicit self.timer.Destroy() somewhere also will not destroy
the timer (=> needs explicit self.timer.Stop() somewhere)
Are these bugs? Or what is the right way for letting owned objects
like timers join death of the owner window?
I'm pretty sure you need to just use the Stop() method. That's what I
do when I close one of my applications. I catch the close event, and
then stop the timers that are running before I destroy the frame.
yes, timer.Stop() needs explicit call. I also did it in OnClose() so far. This however is a vague method. EVT_CLOSE is not called always, when direct destroy, and it can destroy or not. __del__ is also ..
EVT_WINDOW_DESTROY would be perhaps be the right point of real owner death. why does it not work? Is there a diff to C++ ?
I guess its a bug overall: owned timers (etc) should auto-stop on window death.
···
On Jul 29, 1:48 pm, Robert <kxrobe...@googlemail.com> wrote: