fxruby users - Jan 2007 - Closing a modal FXDialogBox correctly?

Hi,

Very rarely, I have a bug when closing a modal dialog box.

What is the 100% correct way of closing a modal dialog box,
programmatically, from within the dialog code itself?

Until now, I was using:

----------------------
self.handle(self, FXSEL(SEL_COMMAND, ID_ACCEPT), nil)
----------------------

... and it works 99% of the time.

After checking the fox C++ code, I found that such a call triggers code
like: 

----------------------
getApp()->stopModal(this,FALSE);
hide();
----------------------

Where hide() does:

----------------------
if(flags&FLAG_SHOWN){
    killFocus();
    flags&=~FLAG_SHOWN;
    if(xid){
#ifndef WIN32
 
XWithdrawWindow(DISPLAY(getApp()),xid,DefaultScreen(DISPLAY(getApp())));
#else
//      if(getOwner() && getOwner()->id()){
//        SetActiveWindow((HWND)getOwner()->getShell()->id());  // Fix
from Sander
//        }
      ShowWindow((HWND)xid,SW_HIDE);
#endif
      }
    }
----------------------


Is there a chance some code might be executing WHILE the dialog is being
closed, what could explain the crashes? 

I have tried replacing:

----------------------
self.handle(self, FXSEL(SEL_COMMAND, ID_ACCEPT), nil)
----------------------

... with:

----------------------
close
$app.stopModal
----------------------

The "close" function has got code that might help:

----------------------
// Target will receive no further messages from us
setTarget(NULL);
setSelector(0);
----------------------

We''ll see if helps. Unfortunately I cannot reproduce the bug. 



Does anyone have the same rare problem maybe?


Philippe Lang

On Wednesday 31 January 2007 11:11, Philippe Lang wrote:
> Hi,
> 
> Very rarely, I have a bug when closing a modal dialog box.
> 
> What is the 100% correct way of closing a modal dialog box,
> programmatically, from within the dialog code itself?
To close the dialog, the ID_ACCEPT or ID_CANCEL message is
used, which (1) breaks out of the modal loop and (2) hides the
window.

Implied herein is that you''ve started the modal loop via the
dialog''s execute() function [or with runModalFor()].

The modal event loop is a re-incarnation of the event loop which
won''t return to the caller until the stopModal() function is
invoked.

Note that the window argument in runModalFor() and stopModal()
must match up; perhaps that is the problem?

At any rate, a modal loop is required.  

Hope this helps,

			- Jeroen

Jeroen van der Zijp wrote:
> On Wednesday 31 January 2007 11:11, Philippe Lang wrote:
>> Hi,
>> 
>> Very rarely, I have a bug when closing a modal dialog box.
>> 
>> What is the 100% correct way of closing a modal dialog box,
>> programmatically, from within the dialog code itself?
> 
> To close the dialog, the ID_ACCEPT or ID_CANCEL message is used,
> which (1) breaks out of the modal loop and (2) hides the window. 
> 
> Implied herein is that you''ve started the modal loop via the
dialog''s
> execute() function [or with runModalFor()]. 
> 
> The modal event loop is a re-incarnation of the event loop which
> won''t return to the caller until the stopModal() function is
invoked.
> 
> Note that the window argument in runModalFor() and stopModal() must
> match up; perhaps that is the problem? 
Hi,

Thanks for your answer.

I''m starting all the dialogs with a call to "execute", so I
don''t have
to pass any specific parameter as an argument.

Is there a chance there can be in very rare occasions some sort of
"concurrency" problem when closing a dialog which is receving a fox
message mostly in the same time? And that the code triggered by the fox
message relies on a "half-closed" dialog somehow? I ask this because I
got twice a message which is "This FXTextField * already release". All
my dialogs contain at least one "FXTextField"...

Note that I''m using the Ruby bindings. Is there a chance the problems
comes from here?

Regards,

Philippe

On Wednesday 31 January 2007 12:07, Philippe Lang wrote:
> Jeroen van der Zijp wrote:
> > On Wednesday 31 January 2007 11:11, Philippe Lang wrote:
> >> Hi,
> >> 
> >> Very rarely, I have a bug when closing a modal dialog box.
> >> 
> >> What is the 100% correct way of closing a modal dialog box,
> >> programmatically, from within the dialog code itself?
> > 
> > To close the dialog, the ID_ACCEPT or ID_CANCEL message is used,
> > which (1) breaks out of the modal loop and (2) hides the window. 
> > 
> > Implied herein is that you''ve started the modal loop via the
dialog''s
> > execute() function [or with runModalFor()]. 
> > 
> > The modal event loop is a re-incarnation of the event loop which
> > won''t return to the caller until the stopModal() function is
invoked.
> > 
> > Note that the window argument in runModalFor() and stopModal() must
> > match up; perhaps that is the problem? 
> 
> Hi,
> 
> Thanks for your answer.
> 
> I''m starting all the dialogs with a call to "execute",
so I don''t have
> to pass any specific parameter as an argument.
> 
> Is there a chance there can be in very rare occasions some sort of
> "concurrency" problem when closing a dialog which is receving a
fox
> message mostly in the same time? And that the code triggered by the fox
> message relies on a "half-closed" dialog somehow? I ask this
because I
> got twice a message which is "This FXTextField * already
release". All
> my dialogs contain at least one "FXTextField"...
The only thing you need to be aware of is that there is some nastiness
when you use the SEL_COMMAND from FXTextField to close the dialog using
ID_ACCEPT.

This is because the SEL_COMMAND may be generated when you''re focusing
out of the FXTextField into another widget, and this could cause the
FXTextField to commit its value.

The fix is to pass TEXTFIELD_ENTER_ONLY, which will stop FXTextField
from issueing SEL_COMMAND due to focus-out.  

Most likely, however, this is not your problem here.
> Note that I''m using the Ruby bindings. Is there a chance the
problems
> comes from here?
Yes, indeed.  It appears to have to do with the Ruby garbage collector;
I believe Lyle was in the process of fixing this, however.

I''ve bounced this mail to him to see if he''s aware of any
specifics.


		- Jeroen