On Jan 31, 2007, at 10:18 AM, Philippe Lang wrote:
> I told you about this stange bug I have rarely, and that crashes my
> FXRuby application. It happened a few times again since last time, and
> mostly when code is doing something with a modal FXDialogBox, and
> especially closing it.
>
> I made a modification in my code, so we''ll see if it changes
anything,
> but before that, I''d like to know if it sounds
"plausible" to you:
>
> Until now, I was closing my dialogs (from within the dialog itself)
> with:
>
> self.handle(self, FXSEL(SEL_COMMAND, ID_ACCEPT), nil)
>
> I have tried changing this into:
>
> close
> $app.stopModal
>
> (where $app is my application global object)
>
> I do this because I have the impression that some code could still be
> executing WHILE the dialog is closing, which could yield to
> problems. I
> have also the impression that calling "close" and
"stopModal" by hand
> can help... That''s a lot of impressions, I agree!
I don''t really believe it has anything to do with how you''re
closing
the dialog box. I think the problem will ultimately be traced to a
bug in how FXRuby is interacting with Ruby''s garbage collector.
As you''ve mentioned, it''s difficult to consistently reproduce
it, but
one thing you can try to test my theory is to simply disable Ruby''s
GC by adding the line:
GC.disable
In your main program. If your program no longer exhibits the problem
after adding this line, that''s a pretty good sign that it''s a
GC-
related issue.
Another, less severe, work around would be to only create the dialog
box once, and store a reference to it in an instance variable:
@dialog_box = FXDialogBox.new(...)
and when you want to display it, call execute on it:
@dialog_box.execute
> Is there anything like a "message queue" in FXRuby?
I''m not sure what you mean. FOX works directly with the OS message
queue (whether it''s on Windows or X11), but there''s no
directly-
accessible version of that.