Alternative to destroying a dialog? (to avoid segfault)

Desktop wxRuby
1

Hi, I’m running into a problem with a segfault when destroying a Dialog,
which I’ve read is a known problem that occurs when the GC cleans up
after a Dialog that contains a Sizer is destroyed (that’s exactly my
situation). I don’t get a segfault when I remove the destroy call, but
the app doesn’t exit correctly, either–the process silently hangs. Is
there an alternative to destroy or something I can do to avoid the
segfault?

Thanks,
Doug

2

Hi

Doug G. wrote:

Hi, I’m running into a problem with a segfault when destroying a Dialog,
which I’ve read is a known problem that occurs when the GC cleans up
after a Dialog that contains a Sizer is destroyed (that’s exactly my
situation). I don’t get a segfault when I remove the destroy call, but
the app doesn’t exit correctly, either–the process silently hangs. Is
there an alternative to destroy or something I can do to avoid the
segfault?
It’s shouldn’t be a problem. Either:

  1. Your app consists of one or more frames, with dialogs shown at
    various times for particular actions. This is the much commoner case.

For this, the Dialogs should have the appropriate Frame parent as the
first argument to the constructor, not nil. They’ll then be cleaned up
when the dialog is closed - no need to call destroy to exit cleanly.

  1. Your app consists of a single dialog only (no frames etc). This is
    less usual but sometimes appropriate (eg, a simple long-running app
    accessed periodically from a TaskBarIcon).

Then, the parent to the Dialog is nil. As long as the app is running,
use hide() and show() to control the dialog’s visibility. When it’s time
for the app to finish, call destroy() on the Dialog to end.

If this doesn’t help, please post a simple runnable demonstration of the
problem and a bit more info about what you’re trying to achieve.

alex

3

Alex F. wrote:

Hi
[snip]

  1. Your app consists of one or more frames, with dialogs shown at
    various times for particular actions. This is the much commoner case.

For this, the Dialogs should have the appropriate Frame parent as the
first argument to the constructor, not nil. They’ll then be cleaned up
when the dialog is closed - no need to call destroy to exit cleanly.

[snip]

alex

This is what I ended up doing. Actually, the dialog (a series of
dialogs, actually) is displayed prior to the main window of the app
being displayed. The way I originally had the app set up, I couldn’t
set the window to be the parent of the dialogs because it didn’t exist
yet, but I moved some things around so that the window can be the parent
even though it hasn’t been displayed yet.

Thanks for the reply,
Doug