michael@parns.nsc.com (Michael C. Wagnitz) (11/15/89)
In article <2566@goanna.oz.au> dmh@goanna.oz.au (Darren Hosking) writes:
+ The version of xfig I have (1.4.3, X11 patchlevel 6) has a problem inputing
+ text AFTER almost any option in the popup menu (right button) is selected.
+ Text input works fine when xfig is first started but once, say, save is
+ selected in the popup menu you cannot input text. The text input prompt
+ and cursor appear when you click where you want the text but anything
+ typed is not echoed.
+
+ [stuff deleted]
+
+ I have followed through the code and it appears that after using the popup
+ menu keyboard events are not reported.
+
+ [more stuff deleted]
I too have been experiencing 'intermittent' loss of keyboard actions in one
asciiStringWidget in my application. Button actions remain active, but
keyboard actions stop being delivered. The actions can usually be restored
by deleting a particular popup menu created during execution. I say usually,
because sometimes the effect does not seem to be related to creation/deletion
of that popup. Only one (of 4) of the asciiStringWidgets used in my
application is ever affected by this 'bug', and never consistently. Unlike
the above sender, my X11R3 has all nine patches applied. Solution anyone?erik@sravd.sra.JUNET (Erik M. van der Poel) (11/15/89)
In article <167@harley.nsc.com> voder!parns!michael@bloom-beacon.mit.edu (Michael C. Wagnitz) writes: >In article <2566@goanna.oz.au> dmh@goanna.oz.au (Darren Hosking) writes: >+ The version of xfig I have (1.4.3, X11 patchlevel 6) has a problem inputing >+ text AFTER almost any option in the popup menu (right button) is selected. >+ Text input works fine when xfig is first started but once, say, save is >+ selected in the popup menu you cannot input text. The text input prompt >+ and cursor appear when you click where you want the text but anything >+ typed is not echoed. > >I too have been experiencing 'intermittent' loss of keyboard actions in one >asciiStringWidget in my application. If you are using twm, then you may be able to get around this problem by setting NoTitleFocus in your .twmrc. This is only a work-around, and I don't know how to fix the bug if it is indeed a bug. I have tried tracing the Focus events in Xt, and found a curious piece of code in lib/Xt/Event.c: if (gl == NULL) { if (!keyboard_focus) { XtAppWarningMsg(XtWidgetToApplicationContext(widget), "grabError","xtRemoveGrab","XtToolkitError", "XtRemoveGrab asked to remove a widget not on the list", (String *)NULL, (Cardinal *)NULL); } return False; } Why is the warning not produced when we are dealing with keyboard focus? Is this meant to hide a bug in an early version of the server? Any comments from the MIT people?
ricks@shambhala.Berkeley.EDU (Rick L Spickelmier) (11/16/89)
This is your window manager hosing you. I had the same problem with XRN. After a popup window is popped down, all keyboard input would be lost (typing in asciiStringWidgets, accelerators for buttons). Under some window managers the keyboard input would not be lost (uwm for example), but under most of the new generation window managers (gwm, twm) the keyboard input would go away..... The problem has to do with XSetInputFocus. When a popup is popped up, the window manager assigns it focus with: XtSetInputFocus(..., ..., ReverToPointerRoot, CurrentTime). When the popup is popped down, the focus is not reverted back to the previous state (i.e. before the popup appeared). It either goes to the root window or stays with the popup (I'm not sure of which one). The answers I got from those more knowledgable about such things is that your application has to have it's own event handlers for focus in/out and the application must then assign focus back to where you want it. However, since focus was not assigned to any particular widget in the application, but based on where the pointer was positioned, this seemed wrong... Anyway, I got around the problem by having XRN destroy the popup widget after popping it down. This caused the focus to end up in the state it was before the popup appeared. Rick Spickelmier UC Berkeley ricks@berkeley.edu
swick@ATHENA.MIT.EDU (Ralph R. Swick) (11/16/89)
> I have tried tracing the Focus events in Xt, and found a curious piece > of code in lib/Xt/Event.c: The piece of code you cite has nothing to do with focus; it implements the last sentence of section 7.2 of the R3 Xt spec (XtRemoveGrab).