From owner-oi-users Wed Feb 22 09:52:08 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA23804 for oi-users-outgoing; Wed, 22 Feb 1995 09:52:08 -0800 Received: from lim.com (limbbs.lim.com [199.33.241.129]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA23798 for ; Wed, 22 Feb 1995 09:52:04 -0800 Received: from limbgb.lim.com by lim.com (8.6.9/3.1.020695 LIM, Int) via SMTP; id LAA01315 for ; Wed, 22 Feb 1995 11:51:20 -0600 Received: by limbgb.lim.com (4.1/1.1.020695) id AA01197; Wed, 22 Feb 95 11:51:29 CST Date: Wed, 22 Feb 95 11:51:29 CST From: brian@lim.com (Brian G. Benton) Message-Id: <9502221751.AA01197@limbgb.lim.com> To: priag@nsd.3com.com Subject: Re: vanishing dialog box Cc: oi-users@freefall.cdrom.com, brian@lim.com Sender: oi-users-owner@FreeBSD.org Precedence: bulk > 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 > > 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! | +----------------------------------------------------------------------------+