[comp.windows.x.motif] XmUpdateDipslay - the little engine that couldn't

watson@dev1b.mdcbbs.com (06/19/91)

>In comp.windows.x.motif, montnaro@spyder.crd.ge.com (Skip Montanaro) writes:

>>  Can someone comment on my perception of the situation? Whether my ideas are
>>  right or wrong, are there any techniques I can use to remedy my problem?
>>  Currently I just execute several XFlush's in the client after the first
>>  XmUpdateDisplay call to slow the client down. Naturally, this doesn't always
>>    work either. (I could have the client sleep for awhile, but for how long?)

>I have experienced similar problems. Instead of XFlush, I called XSync.
>Calling a pair of XSync and XmUpdateDisplay once ot twice took care of
>and client. Asynchronous parallel processes give me interesting problems.

>Masa


I spent some time wrestling with this problem last summer.  Executing some
variable number of XFlush() and XSunc() calls seemed to work, but this
solution was not acceptable since it seemed arbitrary.

What worked best was making sure the message box was displayed by waiting for
its exposure event (with XWindowEvent()).  

Here's a code fragment to give the general idea.


Catie Watson
McDonnell Douglas Manufacturing & Engineering
Cypress, CA
watson@dev1.mdcbbs.com


void manageWorkInProgress (id, msg, reason)
    Widget id;
    char *msg;
    caddr_t reason;
{
		/* call routine which puts message in box & manages it */
    displayMessageBox (WORKING, msg, NULL); 

		/* block until the message box is displayed */
    waitForExpose (MessBoxes[WORKING].id);
}


void waitForExpose (w)
    Widget w;
{
    XEvent evnt;
    Window win = XtWindow (w);

		/* wait for expose event on window */
    XWindowEvent (displayP, win, ExposureMask, &evnt);
    XtDispatchEvent (&evnt);
    XSync (displayP, 0);
}