pjp@sloth.mlb.semi.harris.com (Pat J. Pinchera) (05/04/91)
Dialog Unmap/'Close' Question:
Note: this a repost of a problem that I had a couple of months ago.
A working solution is proposed below.
When I create 3 Form dialogs, with the hierarchy described below, I attach
UnmapCallbacks to them which take care of some cleaning up for each window
when it is unmapped. This callback is activated when
I select the 'Close' option (Alt+F4) from the Window Menu Button
(the 'Dash' button in the upper left corner of each window).
The problem is when I 'Close' a dialog that has 1 or more children dialogs,
(i.e. "dialog1" or "dialog2"); the UnmapCallback *DOES NOT GET CALLED* for
the children dialogs, even though they disappear. For example, 'Close'
dialog2, then dialog2 & dialog3 disappear, and dialog2 UnmapCallback gets
called but dialog3 UnmapCallback does *NOT*.
I tried the DestroyCallback, but that doesn't seem to get activated for the
children either.
+---------+
| dialog1 |
| +---------+ Widget Hierarchy:
| | dialog2 | dialog1 is parent of dialog2
| | +---------+ dialog2 is parent of dialog3
| | | dialog3 |
+-| | |
| | |
+-| |
| |
+---------+
What can I do so that the children callbacks get activated as well, even though
I didn't explicitly 'Close' them? (They need to do some cleaning up too!)
I did receive one reply telling me to try XmAddWMProtocolCallback, and
check the WM_DELETE_WINDOW protocol. Well I tried several combinations
of this, but to no avail.
However, I did find a working solution to my problem:
Add a destroy callback to each dialog that contains all of the "clean-up
actions" that you want to take place. Also attach an unmap callback to
each dialog, and in it, only have the statement 'XtDestroyWidget(w)',
where w is the widget passed to the callback. What results is the unmap
callback gets called, destroys the widget that you 'closed', and as a
result, destroys the children widgets. Since we've attached a destroy
callback, it gets called for each child dialog, and voila', clean-up
actions take place for each dialog!!!
If you see any problems with the implementation, OR have a better, more
efficient, or more portable method, please respond. I'm not particularly
proud of this solution, but hey, it *does* work.
Patrick Pinchera
Interface & Control Systems, Inc.
Melbourne, FLnazgul@alfalfa.com (Information Junkie) (05/06/91)
> the children dialogs, even though they disappear. For example, 'Close' > dialog2, then dialog2 & dialog3 disappear, and dialog2 UnmapCallback gets > called but dialog3 UnmapCallback does *NOT*. The default action on a CLOSE of a dialog is to unmap it (which is pretty silly, since there is no callback to let you know that it happened). The window manager is nice enough to also unmap the children of the dialog, BUT DON'T RELY ON IT! Other window manager's (olwm in particular) are not so kind. You are best off installing a callback that is called when your window gets a WM_DELETE_WINDOW event and manually unmapping your other windows. > I did receive one reply telling me to try XmAddWMProtocolCallback, and > check the WM_DELETE_WINDOW protocol. Well I tried several combinations > of this, but to no avail. This will work - it just only gets called on the actually dialog that was closed. What you could do is have each child dialog add a protocol callback to its parent dialog so that it will be notified when the parent gets a WM_DELETE_WINDOW. Then have it send a WM_DELETE_WINDOW to itself, so any children of its own will be notified. Alternatively you could just turn off CLOSE in dialogs :-). Note that this problem also exists for children of main windows, and for the case where a main window is iconized. P.S. You should include your address in your .signature. Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.