kmy@mel.dit.csiro.au (Kid Mun Yap) (01/25/91)
Hi everybody, Does anyone know why flushing events using : while (XtAppPending(app_context)) XtAppProcessEvent(app_context, XtIMAll); immediately after an XtPopup(widget, ...) does not flush all the events associated with the widget and its descendants but does so if a delay is introduced in between. The popup widget has a label widget as a child, doing the above without the delay in between causes the popup window to appear without the contents of of the label widget. Only on returning to XtAppMainLoop does the contents appear. This seem to suggest that the expose event which is to cause the contents of the label widget to be drawn is not being sent immediately the window is mapped. Is this right? If so, is there a way to force an expose event into the queue. The above mentioned widgets are all from the Athena widget set. Thanks in advance for any help, K M Yap
sivan@bpa_su10.Sbi.Com (Sivan Mahadevan) (01/25/91)
In article <1991Jan25.033150.12714@mel.dit.csiro.au>, kmy@mel.dit.csiro.au (Kid Mun Yap) writes: > Does anyone know why flushing events using : > > while (XtAppPending(app_context)) > XtAppProcessEvent(app_context, XtIMAll); > > immediately after an XtPopup(widget, ...) does not flush all the events > associated with the widget and its descendants but does so if a delay > is introduced in between. > The popup widget has a label widget as a child, doing the above without the > delay in between causes the popup window to appear without the contents of > of the label widget. Only on returning to XtAppMainLoop does the contents I have had this problem using the Motif toolkit, you can flush (or sync) and process all pendings events, and still you don't see the label on the popup. My solution was to flush and then wait for an expose event on the label widget. -- Sivan Mahadevan Salomon Brothers Inc Bond Portfolio Analysis Analytical Applications Group One New York Plaza 44th Floor 212-747-5418 New York NY 10004 sivan@bpa_su10.sbi.com uunet!sbi.com!bpa_su10!sivan
marbru@attc.UUCP (Martin Brunecky) (01/26/91)
In article <1991Jan25.033150.12714@mel.dit.csiro.au> kmy@mel.dit.csiro.au (Kid Mun Yap) writes: > >Does anyone know why flushing events using : > >while (XtAppPending(app_context)) > XtAppProcessEvent(app_context, XtIMAll); > >immediately after an XtPopup(widget, ...) does not flush all the events >associated with the widget and its descendants but does so if a delay >is introduced in between. > Unless you use an override shell, the Map request from the popup will be redirected to the window manager, which may take quite a while to wake up and respond by actually mapping the window. So even if you did XSync(dpy,FALSE) first, your window will NOT be mapped and your expose events will not arrive. The only time you can be assured that your popup is UP is when the Expose or Visibility (if selected) events arrive. It is my belief that you can't even rely on MapNotify, as with reparenting window managers your shell window can be mapped, but if it's parent window is not mapped (yet) it is not on the screen. Now, what I do may sound a little bit crazy - but I have the same problem: need to assure that my popup is completely DISPLAYED before I go on. So my WsPopupWidget code: 1) Checks for special, weird shells used by Motif and does what is appropriate for those .... ick. 2) Calls XtRealize and computations for shell positioning, where necessary. Most people may not need this. 3) Calls XtPopup 4) Finds ALL the WINDOWS (windowObject, managed, mapped when managed) in the popped-up tree. 5) Enters a LOOP waiting for Exposure or Visibility event on ANY of the windows in the tree (XCheckTypedWindowEvent()). Note I am using usleep() (or it's equivalend on non-Sun systems) between my checks to let the server get some CPU cycles. Also note, that since the OpenWindows 2.0 Xserver seems to require occasional kick-in-the-but to wake up, for this server I call XSync(dpy, FALSE) on each loop (you may ask the user to move the mouse around instead -). 6) I keep a counter; if I don't get any event within ... 5 sec ? I just give up, assuming either the Server, WM or something else is broken. This would result in incomplete popup - but I can't wait for ever. 7) As soon as I get the FIRST exposure event, I assume my shell has become visible. Now I traverse my widget tree down again, and for each window object that is managed, mapped-when-managed, realized I call XtDispatchEvent with a manufactured XExpose event - thus forcing it's redisplay without waiting for an XExpose event for this particular widget to arrive. Note if some windows are (partially) obscured, I am displaying more than needed - but the server will clip it off. 8) After I have forced the redisplay, I go into the event queue again, and throw away any XExpose events for windows in my tree. as I already caused an "exposure". Note that not ALL Exposure events arrived at this time, and some may be dispatched later - but a second redisplay will not hurt. All the above implies the knowledge of the Intrinsics to the level any Composite widget writer has to have. It does seem to solve the problem of Transient and other non-override shells. In fact, for override shells I do the same - but without waiting for exposure events (window gets mapped when requested), resulting in much speedier popup. This is something that Motif's MenuShell does (but in less generic way, making typical Motif assumptions about the widget tree layout). Now the ususal disclaimer. This is what *I* do. It does not neceaasy mean it is CORRECT or fully legiment. Any comments are wellcome. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404