wx.lib.pubsub and wx.EVT_CLOSE
Eric Ongerth
ericongerth at gmail.com
Sat Jun 2 20:06:21 PDT 2007
wx.lib.pubsub is making my day... keeping my custom events nice and straight
so that I only have to use regular wx.EVTs where absolutely necessary.
However, I notice that I get PyDeadObjectErrors in the following conditions:
I subscribe a window to some topic, and then somewhere along the way the
same window is closed by the user when they're finished with it, then at
some point the trigger event happens and the topic gets broadcast. Because
wxwindows don't actually get destroyed when they're closed, only hidden, the
Python part of the window is still alive to receive the message it
subscribed to. But if the action it takes in its message handler references
any native C++ part that it contained -- such as altering a text control or
even in some cases referencing variables, a PyDeadObjectError occurs.
So to deal with this, I've been having to manually bind any window that
subscribes to almost anything to wx.EVT_CLOSE, and have the handler for the
close event call Publisher().unsubscribe to unregister the previous
subscription (then of course Skip() the close event so things run properly).
Would it not be more appropriate, and expected, for the pubsub Publisher()
to take care of this? Thinking this through, I guess if you're keeping a
window openable and closable by just showing and unshowing it when
necessary, rather than destroying and recreating it, then you really
wouldn't want it to lose its subscriptions during a time when it was
hidden. What if it didn't update its contents properly (etc.) as a
result...
So would it then be more appropriate, in situations when you wish the
closing of a window to be equivalent to its full destruction, to bind the
close event to a method that calls self.Destroy()? I guess that depends on
your specific purposes and on just how much computation is going into
creating vs. destroying your windows vs. keeping them subscribed to (and
handling) whatever quantity of things they may be hooked up to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wxwidgets.org/pipermail/wxpython-users/attachments/200706=
02/15c41336/attachment.htm
More information about the wxpython-users
mailing list