Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvlx!gabe From: gabe@hpcvlx.cv.hp.com (Gabe Begeddov) Newsgroups: comp.windows.x.motif Subject: Re: Re: XmStringGetLtoR and Loss of Keyboard Focus Message-ID: <110630039@hpcvlx.cv.hp.com> Date: 27 Mar 91 22:56:33 GMT References: <33.27EF5233@resq.fidonet.org> Organization: Hewlett-Packard Co., Corvallis, OR, USA Lines: 65 / hpcvlx:comp.windows.x.motif / Uucp@resq.fidonet.org (Uucp) / 4:56 am Mar 25, 1991 / > An easy fix that I incorporated into my code was to use > XtUngrabKeyboard directly before displaying any dialog. Note > that I only do this if the pop-up dialog shell's parent widget is > realized and I pass the parent widget as a parameter to the routine. > Because the routine checks for grab conditions before doing > an XUngrabKeyboard, it causes no X errors and because it never > uses the widget, except to get the display/screen info, it isn't > too picky about what widget is used. I'm getting sick and tired of this bug. I don't see it, incidentally on my dialogs, but rather on a main window that I invoke and close using accelerators. It's clearly a focus problem, because whenever it happens I can press Alt-F to bring up the File menu and it will bring up the File menu in the *old* window. In fact, it will even do this if the old window is no longer mapped. Of course this results in an X error when it unmaps it, but fortunately I trap those. I think this problem is caused by the inability of the Xt passive grab routines (Xt[Un]Grab[Key,Button]) to always tell when a grab has been released. The Xm menu accelerators are layered on top of the Xt passive grab facility which are in turn layered on top of the server passive grabs (X[Un]Grab[Key,Button]). One of the reasons the Xt wrappers were added was to avoid event processing mishaps when toolkits/apps tried to mix X style event redirection (via grabs and X focus) with Xt style event redirection (via XtSetKeyboardFocus and the modal cascade). Xt keeps enough state around to recoginize when a passive grab has activated by checking incoming press events in a manner similar to the way the server recognizes grabs. The way that Xt recognizes that the grab has gone away is to look at release events and if they match up with a press that has caused a grab then it goes away. Again, similar to the server. Unfortunately, this isn't good enough. There are at least two situations where Xt currently misses grab releases and therefore merrily continues to enforce the grab. In your situation it would cause events to continue to be forwarded to the hierarchy that you had unmapped. The first is when the grab window becomes unviewable (it or one of its ancestors is unmapped). The server will release the grab but Xt would need to do some extra work in order to infer unviewabilility and thereby know that the grab has been released. If the window underneath the window that was released doesn't happen to have release interest expressed on it by this application's connection then the eventual keyrelease won't even be seen by this client ! That is the second problem area. While the server sees all events on all windows :-), the client has to explicitly request events. If the keyrelease were to occur in a window that doesn't have release interest Xt will never see it and will be unable to recognize that the grab has been released. These are both problems with the Xt implementation of passive grabs. One way that we found to avoid this problem is to always specify the menu accelerators and mnenomics as being activated on the release rather than the press. You can even argue that this is more compatable with the way that buttons are activated, i.e. on release. You do this by explicitly specifying the accelerator values as "MyKey". It looks like the documentation (Label) says you should only use keypress events but the implementation actually uses KeyUp for all mnemonics and works if you use it in your label accelerator resource spec. I think the documentation should be changed. As far as the Xt bugs go, maybe a workaround, or even a real fix will be available for R5. Gabe