heap@bmc.uu.se (10/01/90)
I have a little problem with the usage of XmMessageBox of type WORKING.
I want to be able to pop up a WORKING dialog to inform the user that
he will have to wait for a while. After the computation (or whatever) is
finished the dialog should automatically disappear (i.e. the program takes care
of the unmapping).
Example:
PopupWorkingDialog("Saving file");
SaveFile();
PopdownWorkingDialog();
The problem is to get the dialog window is displayed properly.
I use the following code to get the dialog displayed in the routine
"PopupWorkingDialog" :
dialog = CreateWorkingDialog(...);
< unmanage all buttons ... >
XtManageChild(dialog);
while (XtAppPending(appcontext) != 0) {
XtAppNextEvent(appcontext,&event);
XtDispatchEvent(&event);
}
With this code the window of the dialog is displayed but not the text in it !
If I turn the loop into a for-loop and loop 50 times everything in the dialog
window is displayed properly (but that is not a real solution).
What is the correct solution ? To handle some event that tells me when the
window is finished displayed by the server ?
I have also tried XPending abd XFlush with no success.
Many thanks in advance for any directions.
--
----------------------------------------------------------------------
Per Bengtsson, Dept. of Scientific Computing, Univ. of Uppsala, Sweden
Internet: heap@tdb.uu.se
Sunet/Decnet: tdb::heap
----------------------------------------------------------------------nazgul@alphalpha.com (Kee Hinckley) (10/05/90)
> I have a little problem with the usage of XmMessageBox of type WORKING.
This will work most of the time.
Create and manage your dialog
Create a timer with a zero second timeout
In the timer callback start your work
Note that if possible you should still check for events while
you are working so that the user can cancel if they want to.heap@bmc.uu.se (10/10/90)
I received another solution of my problem, it doesn't use Xt-calls but is more compact and reliable than "my own" solution. It was (most kindly) mailed to me by cuweiss.US2.oramail@us.oracle.com. She didn't think that the original author would have anything against it being posted. So here it comes : =============================================================================== Received: 06-01-90 21:07 Sent: 06-02-90 00:03 From: kit@expo.lcs.mit.edu <DVLSEQ:kit@expo.lcs.mit.edu> To: cuweiss.US2.oramail@us.oracle.com Subject: Re: Code for working around timing problems in X Cc: kit@expo.lcs.mit.edu kit@expo.lcs.mit.edu Reply-To: DVLSEQ:kit@expo.lcs.mit.edu In-Reply-To: Your message of Fri, 25 May 90 15:51:20 -0700. Anything like this is a kludge at best, and if you are not very careful you can get into trouble. Bad things can happen, like you application will hang waiting for an event that will never come. Keeping that in mind, here is one method of coding that will block until an expose event occures in the widget specified. No remember that an obscured widget will never receive an expose event, so it is important that you KNOW that the widget in question will be visable. Not just mapped, but it can also no be obscured by any other widget. This code also only returns one expose event. Expose events may come in groups, since they contain a rectangle that is the region that has been exposed. Consider the case of when an "L" shaped region has been uncovered. There are two possibilities, you can either return two expose events One for this part of the L "|" and one for this part "_". Or you could return a rectangle containing the entire box that contines the L (this also gives you some region that does not need to be repainted). Because you only get one expose event your widget may not repaint the entire widget, but just part of it. I know this all sounds like pretty ominous, but I just want you to understand that you are breaking the rules here a bit, so you had better know what you are doing. I have used this code in one of my applicaions, and it works just fine. Without further adoo... Widget widget; XEvent event; while ( !XCheckTypedWindowEvent(XtDisplay(widget), XtWindow(widget), Expose, &event) ); XtDispatchEvent( &event ); XFlush(XtDisplay(widget)); This is by no means the only way to do this, using the Xlib functions that let you peek into the event queue, you can see that there are many ways to accomplish the same task. I hope this helps you solve your problem. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213 -- ---------------------------------------------------------------------- Per Bengtsson, Dept. of Scientific Computing, Univ. of Uppsala, Sweden Internet: heap@tdb.uu.se Sunet/Decnet: tdb::heap ----------------------------------------------------------------------
heap@bmc.uu.se (10/15/90)
In article <9010101547.AA05309@bellcore.bellcore.com>, aw@KITCHEN.BAE.BELLCORE.COM (Andrew Wason, aw@cellar.bae.bellcore.com) writes: > > Could you use XmUpdateDisplay(workdialog) to make sure > the dialog box is completely drawn before doing your long computation. > I haven't tried this, so I don't know if it would work or not, > but the manual suggests that this is what this function is for. > > Andrew > I tried this call, but it gives me the same result as my original code did (that is, the window of the workingdialog is displayed, but not its contents). Am I supposed to use XmUpdateDisplay on every little subwidget in the dialog (or should I have used something else than the widget returned from XmCreateWorkingDialog as the parameter to XmUpdateDisplay) ?? ---------------------------------------------------------------------- Per Bengtsson, Dept. of Scientific Computing, Univ. of Uppsala, Sweden Internet: heap@tdb.uu.se Sunet/Decnet: tdb::heap ----------------------------------------------------------------------