[fxruby-users] This FXTextField * already release
lyle at knology.net
Fri Feb 2 11:20:53 EST 2007
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)
> self.handle(self, FXSEL(SEL_COMMAND, ID_ACCEPT), nil)
> I have tried changing this into:
> (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:
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-
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:
> 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.
More information about the fxruby-users