Re: [Foxgui-users] FXDialogBox::ID_CLOSE versus FXDialogBox::ID_CANCEL

[<je...@fo...>]

On 2023-07-26 09:21, John Selverian wrote:
> I'm running on Win11 with v1.7.50
> 
> 
> 
> When I use this:
> 
> 
> 
>                 new FXButton(bottom_HF_0, "Close", nullptr, this,
> FXDialogBox::ID_CLOSE, FRAME_RAISED | FRAME_THICK |
> BUTTON_DEFAULT);
> 
> 
> 
> the program crashes:
> 
> 
> 
> 
> 
> when I use this
> 
> 
> 
>                 new FXButton(bottom_HF_0, "Close", nullptr, this,
> FXDialogBox::ID_CANCEL, FRAME_RAISED | FRAME_THICK |
> BUTTON_DEFAULT);
> 
> 
> 
> 
> 
> it doesn't.what's the difference?

A great deal has probably been left out of the picture.

FXTopWindow::close(notify) notifies the target (if there is one
and notify is true) about the imminent close.

If there is no objection, or no target, or no need to notify, then
it proceeds to close the toplevel window.

If its the last such window, then it will self-destruct.

This logic is intented for top-level windows, not FXDialogBoxes.

The FXTopWindows are dynamically allocated, and typically not run
in modal loops.

For FXDialogBox, we prefer ID_CANCEL or ID_ACCEPT.  One breaks out
of the modal loop with false, the other breaks out of the modal
loop with true.

Either way, clean up of the FXDialogBox (or its subclass) is left
on the caller of the modal loop.

The FXDialogBox still exists at this point, and if allocated on the
stack it will simply go out of scope and delete everything from the
parent on down.

If you run non-modal dialog boxes then you must make other arrangement
to delete them.

For FXTopWindow's like FXMainWindow, these are usually long-lived
and don't live on the stack as local variables, since they're not
executed from modal loops.

The close() would therefore delete them.

In a nutshell, don't call delete on windows that are not dynamically
allocated, and thus don't call close() on such windows.

    -- JVZ