Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!paperboy!osf.org!dbrooks From: dbrooks@osf.org (David Brooks) Newsgroups: comp.windows.x.motif Subject: Re: XmUpdateDisplay fails Message-ID: <20738@paperboy.OSF.ORG> Date: 5 Apr 91 17:32:40 GMT References: <1991Apr5.153900.22674@athena.mit.edu> Sender: news@OSF.ORG Distribution: inet Organization: Open Software Foundation Lines: 29 alice@athena.mit.edu (Timothy R Wall) writes: |> I use XmUpdateDisplay to refresh my application before starting a long |> load from disk and subsequent calculation. Immediately after |> XmUpdateDisplay I call a routine to change the cursor, which calls |> XFlush; I see the cursor change, but no screen update. What's wrong? The cursor change is done by the server, and happens as soon as it gets the request. No mystery there. XmUpdateDisplay performs a XSync(), and then processes all outstanding events. What it must not do is block. The theory is that after the Sync, all the Expose events resulting from mapping the dialog windows (the commonest use of this) are in the Xlib queue and can be processed before continuing. This turns out not to be the case. The server may have delivered the events, but the client hasn't received them yet. There's a timing issue, which may (or not) involve the window manager, and some of us are looking into a better solution. For now, you can try: XSync(XtDisplay(toplevel), 0); usleep(); XmUpdateDisplay(toplevel); where on my workstation is 60000. -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks Experience is what lets us recognize a mistake the second time we make it.