Date: Wed, 22 Feb 95 11:51:29 CST From: brian@lim.com (Brian G. Benton) To: priag@nsd.3com.com Cc: oi-users@freefall.cdrom.com, brian@lim.com Subject: Re: vanishing dialog box Message-ID: <9502221751.AA01197@limbgb.lim.com>
next in thread | raw e-mail | index | archive | help
> From owner-oi-users@freefall.cdrom.com Wed Feb 22 11:06:17 1995
> To: oi-users@freefall.cdrom.com
> Subject: vanishing dialog box
> Phone.......: (408) 764-6204 (Office)
> (408) 764-5000 (General Office)
> Date: Wed, 22 Feb 1995 08:25:13 -0800
> From: priag <priag@nsd.3com.com>
>
> Hi -
>
> We have an application which uses an object subclassed from
> OI_dialog_box to display results of a long-running operation. If the
> user closes the dialog box while the operation is running, I need
> to terminate that operation since there's no longer any place to
> display the output.
>
> If the user selects the abort button on the dialog box,
> everything works fine: I clean up and close the window.
>
> If the user dismisses the window from the window decoration, however,
> I can't get the behavior I want. Since the operation may run for
> quite a while, I would like to be able to prompt the user and
> dismiss the window/cancel the operation ONLY if the user confirms.
> In fact, my unpin callback gets called, but even if I return without
> taking down the window, OI makes it disappear after I return
> (apparently setting state to OI_not_displayed - it's not destroyed,
> just not visible).
>
I am assuming that you are using a Modal Dialog in this case.
I had what I think is a similar problem with multiple modal dialogs.
Ex. Modal Dialog A is active. The user selects a button in A that
spawns a new Modal Dialog B. B is now the active Dialog as the user
can no longer interact with A. However, the user can still select
the close entry from the window manager menu on Dialog A.
The following occurs when this happens:
1) My UnpinCB for Dialog A gets called
2) Modal Dialogs A&B are dismissed from the screen
3) The wait_button event loop of Dialog B is exited
4) Since a button in the button menu of Dialog B was never
selected, the Validation callback for B is never called
5) The callback in Dialog A (which spawned Dialog B) completes
6) The Validation callback for Dialog A is called
At this point (inside the Validation callback of A), we don't want to
send back a FALSE value if the Dialog is not visible (OI changed
the state of Dialog A & B to OI_not_displayed or OI_active_not_displayed,
depending on how it is parented). If we did, we would
stay in the wait_button loop of Dialog A with no Dialog in which to interact.
Hence, we need to send back a value of TRUE in this case.
Thus, I think if you provide a Validation callback testing for the above,
it might solve your problem. It solved mine.
Here is what I did:
if ((ValidContents() == OI_YES)
((state() == OI_not_displayed) !! (state() == OI_active_not_displayed)))
return 1;
ValidContents() is merely a member function in my base Dialog class (which is
subclassed from OI_dialog). It allows me to check the state of the ValidContents
instance variable which I set depending on the validity of the Dialog contents.
Subclassed from Dialog, I have ModalDialog and ModelessDialog (which are also
abstract classes).
Obviously your code would be slightly different, because you want to react differently,
but the information you need is here. I assume you would want to post
a Confirmation Dialog if the user dismisses via the window manager menu.
In your case, you might want to make the Dialog visible once again
after it's state has been changed by OI. But you will be able to
tell if the Dialog has been brought down
via the window manager menu and can act accordingly. Unfortunately,
there is no way to catch the window manager selection in Dialogs as you
can with OI_app_windows. That would solve this whole mess by allowing
you to react before the Dialog disappears. I have been told by Openware
that it can't be done. :-(
> Is there any way to prevent this? I tried adding a terminate call
> back but it doesn't get called unless a button is selected. Any other
> ideas?
Ooops. My case assumes that a button is selected from the button menu at
the bottom of the Dialog, which was true for Dialog A in my example.
This is why the Validation callback for A is obviously called.
Why not make the select() method call on one of your menu cells in
the Dialog menu? This should be the same as the user selecting
the cell.
Ex. Have a Cancel button (menu cell) which does exactly the same thing
as the 'close' entry on the window manager. When your unpin callback
is called, select the Cancel button programatically. This will cause
your Validation (terminate) callback to get called after OI changes the
state of the Dialog. It's a hack, but worth a try.
>
> Thanks,
>
> Pria Graves
>
+----------------------------------------------------------------------------+
| Brian Benton | Phone: (512) 346-5464 x21 |
| Sr. MTS | Fax: (512) 346-5386 |
| LIM International | Email: brian@lim.com |
| 9390 Research Blvd., Kaleido II, #300 |------------------------------------|
| Austin, TX 78759 | GO BRONCOS! GEAUX CAJUNS! |
+----------------------------------------------------------------------------+
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502221751.AA01197>