wxruby users - Sep 2008 - alternative to destroying a dialog? (to avoid segfault)

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
-- 
Posted via http://www.ruby-forum.com/.

Hi

Doug Glidden 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.

2) 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

Alex Fenton 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
-- 
Posted via http://www.ruby-forum.com/.