zjmw36@trc.amoco.com (Joe M. Wade) (12/27/90)
In article <421@nec-gw.nec.com>, achan@sparkle.nec.com (Amy Chan) writes: |> >> |> >>How can I ensure that a warning dialog widget disappears IMMEDIATELY after |> >>clicking on (any of the buttons) OK or CANCEL OR HELP? |> >>I tried putting XtDestroyWidget(w) as the 1st statement of the callback, |> >>but It does not do the trick! |> >>The dialog box seems to disappear only after the callback associated with any |> >>of these buttons terminates!! |> >> |> |> Set the XmNautoUnmanage resource of your warning dialog widget to True. |> No, the problem is that the callbacks get called before the dialog widget gets the unmanage from the motif code. I did just the opposite of your advice and set the XmNautoUnmanage resource to False. I then set up my own callback which does the XtUnmanageChild. That callback gets called before my other callback which is going to bring up the dialog again. That was good enough for my snafu. Hopefully it will also work for the original poster. Happy Holidays !! -- * * * * * * * * * * * * * * * * * * * * * * * Joe M. Wade (jwade@trc.amoco.com) (918) 660-4387 * * Amoco Research Center * 4502 E. 41st St. * Tulsa, OK 74102 * * * * * * * * * * * * * * * * * * * * * * * -- * * * * * * * * * * * * * * * * * * * * * * * Joe M. Wade (jwade@trc.amoco.com) (918) 660-4387 * * Amoco Research Center * 4502 E. 41st St. * Tulsa, OK 74102 * * * * * * * * * * * * * * * * * * * * * * *
argv@turnpike.Eng.Sun.COM (Dan Heller) (12/30/90)
In article <9602@ncar.ucar.edu> morreale@bierstadt.scd.ucar.edu (Peter Morreale) writes: > >How can I ensure that a warning dialog widget disappears IMMEDIATELY after > >clicking on (any of the buttons) OK or CANCEL OR HELP? > >I tried putting XtDestroyWidget(w) as the 1st statement of the callback, > >but It does not do the trick! > >The dialog box seems to disappear only after the callback associated with any > >of these buttons terminates!! > > > Perhaps you need to Unmap the widget??? You needed to process the X events that are generated from the widget's destruction and unmapping.... but this seems to be old news now... > >Also, I would like to display (and remove) the Motif hourglass to indicate > >that there is work in progress. How can I do this? > What I did, (Thank you der mouse!) is to create an InputOnly window > covering the toplevel window for the duration of the work in > progress. The only attribute I gave the window was a "watch" cursor. > I simply map the window just prior to starting the work, and unmap it > after the work is done. Works like a charm, nice visual too. This sounds identical to the solution I posted to thise newsgroup a couple of months ago. However, my implementation had some quirks in it that aren't very nice given other, less likely (but possible) circumstances. I didn't figure out at the time, but now that I have, I'm worried that "bad code" is being circulated. Send me what you've got so I can check. If you have something different, maybe I can learn something new from it. There are also other possible solutions without using InputOnly windows now, but I don't want to get into that out of context of this discussion. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
huw@siesoft.co.uk (Huw Roberts) (01/04/91)
> How can I ensure that a warning dialog widget disappears IMMEDIATELY after > clicking on (any of the buttons) OK or CANCEL OR HELP? > I tried putting XtDestroyWidget(w) as the 1st statement of the callback, > but It does not do the trick! > The dialog box seems to disappear only after the callback associated with any > of these buttons terminates!! I have the opposite problem - I am using an ErrorDialog to display an error to the user. The user has the option either to continue regardless or to cancel the operation, but he can also get help (another dialog) to allow him to make the decision. My problem is that when the user selects the help button, the error dialog is removed from the screen so he is unable to then choose one of the other options. I want to retain the ErrorDialog until the user chooses one of the other options. (I am using XmCreateErrorDialog followed by XtManageChild to display the widget and am not destroying or unmapping it subsequently) Thanks, Huw
nazgul@alphalpha.com (Kee Hinckley) (01/05/91)
> My problem is that when the user selects the help button, the error dialog is > removed from the screen so he is unable to then choose one of the other > options. I want to retain the ErrorDialog until the user chooses one of the > other options. Look at the resources for bulletinboard (which is what is returned when you create an error dialog). Set autoUnmanaged to False and do the unmanage yourself at the right time. BTW. Include a .signature if you want replys to make it to you.
zjmw36@trc.amoco.com (Joe M. Wade) (01/10/91)
In article <1991Jan4.143707.1758@siesoft.co.uk>, huw@siesoft.co.uk (Huw Roberts) writes: |> |> I have the opposite problem - I am using an ErrorDialog to display an error |> to the user. The user has the option either to continue regardless or to cancel |> the operation, but he can also get help (another dialog) to allow him to make |> the decision. |> My problem is that when the user selects the help button, the error dialog is |> removed from the screen so he is unable to then choose one of the other |> options. I want to retain the ErrorDialog until the user chooses one of the |> other options. |> |> (I am using XmCreateErrorDialog followed by XtManageChild to display the |> widget and am not destroying or unmapping it subsequently) |> |> Thanks, Huw Setting XmNautoUnmanage attribute on your dialog should make it stay up when your help button is pushed. However, you will have to do the XtUnmanage yourself for your other buttons for which you want the dialog to go away. You can either add a callback on each button which unmanages the dialog or you can add the call at the top of any existing callbacks that you have. -- -- * * * * * * * * * * * * * * * * * * * * * * * Joe M. Wade (jwade@trc.amoco.com) (918) 660-4387 * * Amoco Research Center * 4502 E. 41st St. * Tulsa, OK 74102 * * * * * * * * * * * * * * * * * * * * * * *