From: leiman@armos.engr.washington.edu (Ian Leiman)
Newsgroups: comp.windows.x.motif
Subject: Re: XmMessageBoxProblem (dispactching the events before starting)
Keywords: messagebox
Date: 14 Nov 92 01:00:37 GMT
Article-I.D.: u.1992Nov14.010037.10317
Reply-To: leiman@armos.engr.washington.edu (Ian Leiman)
Organization: University of Washington

In article <Bx968I.3z6@ccu.umanitoba.ca>, clhawth@ccu.umanitoba.ca (Timothy Chesley) writes:
> 	I am trying to pop up a working message while my program does
> some large processing.  Within a callback I popup the warning box
> and then start the processing.  The problem is that the label and the
> buttons on the message box do not appear until after the callback from
> which I popped the message box is finished.  I have tried using 
> XmUpdateDisplay and XFlush to get the requests done before I make the call
> to the time consuming procedure.   Any help in this problem would be much 
> appreciated.

Your real problem here is really simple to answer: since you are not returning 
control back to the XtMainLoop (by returning from your callback), NOTHING
ABOSLUTELY NOTHING is going to happen with your application interface, no matter
how many XFlush calls you make (or badly timed XmUpdateDisplay()s).

The XtMainLoop of your application will get and dispatch the nescessary 
expose events, generated by the XmCreateMessageBox or equivalent calls
which create a new X window. Unless you let the XtMainLoop run long enough
to process these events your, dialog is not going to appear on screen. It
will however appear after you return from the 'large processing' callback.

There's several ways to get that dialog up while doing heavy processing in
the same process:
1) use the Work Procedure facility as suggested in another article (see
   O'Reilly VOL 6 section 20.2.1), but this is really meant for continious
   background processing and not for temporary crunching.
2) Use XtAppProcessEvent in your processing loop to handle X-events while
   doing the heavy stuff, this keeps your interface running nicely. Not only
   will the dialog pop up, but suppose user shuffeled the application windows
   around and they would need to get redrawn, those expose events would now be
   handeled in due time.

Why is XmUpdateDisplay not providing desired results here is explained in
O'Reilly VOL6 sec 20.2.4 Caveats using XmUpdateDisplay(). Some workarounds
are discussed there, but method 2) is surely going to work as I have used it 
myself most succesfully.

Here is the basic idea how to do 2):
do {
  if (XtAppPending(app_context))
     XtAppProcessEvent(app_context, XtIMAll);
   XSync(XtDisplay(app_shell, False);
   /* do the heavy processing here */
} while (/* heavy processing not ready */);

here the app_context should be the XtAppContext created by your XtAppInitialize,
app_shell your application shell Widget returned by the same.
The XtAppPending will check wheteher there are any events pending before calling
XtAppProcessEvent (which would otherwise block-up and hand-up your heavy 
processing).
XSync will only flush the X-server event queue, it WILL _NOT_ dispatch any events.

For more info about this look at O'Reilly VOL4, chapter 8 about events and
9.3 for handling them.



Ian Leiman, M.Sc.(EE)            leiman@armos.engr.washington.edu
Visiting Scientist, CISO
University of Washington         office: +1 206 685-2872 
Ian Leiman, M.Sc.(EE)            leiman@armos.engr.washington.edu
4106 Dayton Ave. North           home:   +1 206 545-4967
Seattle, WA 98103                office: +1 206 685-2872 (UW/CISO)
Newsgroups: comp.windows.x.motif