I have what I suspect is a common problem, an operation takes a long
time so I get a worker thread to call do it, and post updates the the
main thread with pubsub (called with wx.CallAfter() of course). The
main thread calls the Update method on a ProgressDialog instance. All
is lovely. However, if I manually call Destroy() on the
ProgressDialog, the app crashes. Using the wx.PD_AUTO_HIDE style on
the ProgressDialog and _NOT_ calling Destroy() makes it all work.
What kind of crash is happening? Is there a traceback?
I suspect that it is possible that if you didn’t unsubscibe your reciever(s) before calling Destroy that pubsub might be calling them after the object is dead, but without more info its hard to say.
I have what I suspect is a common problem, an operation takes a long
time so I get a worker thread to call do it, and post updates the the
main thread with pubsub (called with wx.CallAfter() of course). The
main thread calls the Update method on a ProgressDialog instance. All
is lovely. However, if I manually call Destroy() on the
ProgressDialog, the app crashes. Using the wx.PD_AUTO_HIDE style on
the ProgressDialog and NOT calling Destroy() makes it all work.
Actually what might happen is that there are multiple subscribers, and that they therefore try to close the ProgressDialog multiple times?
I added an extra flag on the progress-dialog instance, ‘destroyed’, which I set to True before calling Close and Destroy and which I check for being True before actually doing the close/destroy.
That prevented a couple of edge-cases where my code could crash closing the same ProgressDialog twice
What kind of crash is happening? Is there a traceback?
I suspect that it is possible that if you didn’t unsubscibe your reciever(s) before calling Destroy that pubsub might be calling them after the object is dead, but without more info its hard to say.
There is no traceback, just an access violation (what Windows calls a
segfault). I am absolutely sure that I am not calling methods on the
object after I call Destroy(), or calling Destroy() twice, since I
have put trace prints in the handlers. There are no inter-thread calls
that are not done with wx.CallAfter().
Calling Close() before Destroy() does not solve the problem.
I might try to reproduce the problem with some minimum code, just out
of interest.
Thanks for the quick replies.
On the bright side my app looks great with a real progress dialog with
the times etc, all done for me. Thanks to wx. The non-functioning
Destroy() is quite inconsequential, I just hate it when I can't get
something to work properly (and it sounds like it's my fault).
···
--
Tom Harris <celephicus@gmail.com>
On Wed, Sep 10, 2008 at 11:14 PM, Tim van der Leeuw <tnleeuw@gmail.com> wrote:
On Wed, Sep 10, 2008 at 3:11 PM, Cody Precord <codyprecord@gmail.com> wrote:
Hello,
What kind of crash is happening? Is there a traceback?
I suspect that it is possible that if you didn't unsubscibe your
reciever(s) before calling Destroy that pubsub might be calling them after
the object is dead, but without more info its hard to say.
Actually what might happen is that there are multiple subscribers, and that
they therefore try to close the ProgressDialog multiple times?
I added an extra flag on the progress-dialog instance, 'destroyed', which I
set to True before calling Close and Destroy and which I check for being
True before actually doing the close/destroy.
That prevented a couple of edge-cases where my code could crash closing the
same ProgressDialog twice
