Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!kddlab!titcca!sragwa!sravd.sra.JUNET
From: erik@sravd.sra.JUNET (Erik M. van der Poel)
Newsgroups: comp.windows.x
Subject: Re: bug in Xaw asciiStringWidget
Message-ID: <1267@sragwa.sra.JUNET>
Date: 15 Nov 89 14:45:41 GMT
References: <167@harley.nsc.com> <2566@goanna.oz.au>
Sender: news@sragwa.sra.JUNET
Reply-To: erik@sra.co.jp (Erik M. van der Poel)
Organization: Software Research Associates, Inc., Japan
Lines: 35


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?