Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!montnaro From: montnaro@spyder.crd.ge.com (Skip Montanaro) Newsgroups: comp.windows.x.motif Subject: XmUpdateDisplay - the little engine that couldn't? Message-ID: Date: 17 Jun 91 19:38:35 GMT Sender: news@crdgw1.crd.ge.com Reply-To: montanaro@crdgw1.ge.com (Skip Montanaro) Organization: GE Corporate Research & Development, Schenectady, NY Lines: 27 In my application I popup an XmMessageDialog widget before launching into a long operation. I've experimented with calling XmUpdateDisplay one or more times before the operation, in an attempt to force the message to display properly. My experiments have been unsuccessful thusfar. The mental picture I have of the situation is that there is an expose event for the outer DialogShell widget in the input queue when XmUpdateDisplay is called initially. The call processes that expose event, which generates one or more other expose events for the XmMessageBox child of the DialogShell. These aren't seen by the first call to XmUpdateDisplay, so you have to call it again. Unfortunately, there is a race between the client and server to see whether the server can send the expose event(s) before the next call to XmUpdateDisplay. If it can, the second call will cause the message to be displayed. If not, the second call will see no expose events in the queue and return without doing any useful work. 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?) Thx, -- Skip (montanaro@crdgw1.ge.com)