moore@cs.cmu.edu (Dale Moore) (02/09/90)
I'm not real familiar with the protocol on this particular newsgroup,
so please be patient with me if I do something anti-social.
I suspect I've found a problem with XtSetKeyboardFocus.
Under certain situations it is possible to cause a protocol
error by calling this routine. If the subtree widget is not
yet realized, we end up passing 0 as the window to the XQueryPointer
routine, which of course doesn't work.
This bug appears to be present in the X11-R4beta release.
Below is a program that should cause the error.
Am I halucinating? Or is it really a bug? Does anyone care?
Does anyone want a fix? Does anyone have a fix?
----------------
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
#include <X11/Xaw/Box.h>
#include <X11/Xaw/Command.h>
#include <X11/Xaw/Dialog.h>
char dialog_string[100];
static void button_callback (w, client_addr, client_data)
Widget w;
XtPointer client_addr;
XtPointer client_data;
{
Widget dialog;
Arg args[10];
Cardinal num;
num = 0;
XtSetArg (args[num], XtNlabel, "dialog"); num++;
XtSetArg (args[num], XtNvalue, dialog_string); num++;
/* This program will have an error when this widget is created */
dialog = XtCreateWidget (
"dialog",
dialogWidgetClass,
XtParent (w),
args,
num);
XtRealizeWidget (dialog);
XtMapWidget (dialog);
}
main(argc, argv)
int argc;
char *argv[];
{
XtAppContext app_context;
Widget top;
Widget box;
Widget button;
top = XtAppInitialize (
&app_context, /* app_context */
"foo", /* class */
NULL, /* options */
0, /* num_options */
&argc, /* argc */
argv, /* argv */
NULL, /* fallback resources */
NULL, /* args */
0); /* num_args */
box = XtCreateManagedWidget ("box", boxWidgetClass, top, NULL, 0);
button = XtCreateManagedWidget ("go", commandWidgetClass, box, NULL, 0);
XtAddCallback (button, XtNcallback, button_callback, 0);
XtRealizeWidget (top);
XtAppMainLoop (app_context);
}swick@ATHENA.MIT.EDU (Ralph R. Swick) (02/10/90)
I suspect I've found a problem with XtSetKeyboardFocus.
Yep, you have.
This bug appears to be present in the X11-R4beta release.
And in the R4 release bits, even though this code was substantially
re-worked after beta (I'll not say by whom, to protect the guilty :-(.
The problem occurs when setting the keyboard focus for an unrealized
descendant of a realized shell. I can't think of an easy work-around,
except to make sure the descendant is realized before calling
XtSetKeyboardFocus. Unfortunately in the example you provided,
the call is internal to the Dialog widget so you've not much choice.
If you need a quick fix, add "&& XtIsRealized(widget)" to the
outermost conditional around the block of code in AddFocusHandler().
An official patch will be forthcoming.gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (02/10/90)
/ hpcvlx:comp.windows.x / moore@cs.cmu.edu (Dale Moore) / 12:34 pm Feb 8, 1990 /
This bug appears to be present in the X11-R4beta release.
Try it with the R4 release. The keyboard logic has undergone large changes.
Below is a program that should cause the error.
Am I halucinating? Or is it really a bug? Does anyone care?
Does anyone want a fix? Does anyone have a fix?
If it's really a reasonable bug rather than the place an already sick program
happens to expire, then I'm sure *someone* cares. Now to some comments on the
program. I am not familiar with the Xaw widgets (especially after some of the
dramatic improvements that Chris Peterson et al have made for R4) but it
seems like your logic for the dialog creation is way off. You are creating the
dialog (which is a form subclass) as another child of your box. Do you want it
there or in a seperate popup? Either way it should be managed (via XtManageChild)
rather than realized (which should usually be reserved for the roots of widget
hierarchies). If you still see strange behavior then send a bug report to:
xbugs@expo.lcs.mit.edu
there's a form in the /doc (?) directory of the X11 distribution.
static void button_callback (w, client_addr, client_data)
{
dialog = XtCreateWidget (
"dialog",
dialogWidgetClass,
XtParent (w),
args,
num);
> XtRealizeWidget (dialog);
> XtMapWidget (dialog);
use XtManageChild(dialog);
----------
Gabe Beged-Dov
Iterface Technology Operation
Hewlett-Packard
gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (02/12/90)
/ hpcvlx:comp.windows.x / swick@ATHENA.MIT.EDU (Ralph R. Swick) / 8:05 am Feb 9, 1990 /
I suspect I've found a problem with XtSetKeyboardFocus.
Yep, you have.
This bug appears to be present in the X11-R4beta release.
And in the R4 release bits, even though this code was substantially
re-worked after beta (I'll not say by whom, to protect the guilty :-(.
The problem occurs when setting the keyboard focus for an unrealized
descendant of a realized shell. I can't think of an easy work-around,
except to make sure the descendant is realized before calling
XtSetKeyboardFocus. Unfortunately in the example you provided,
the call is internal to the Dialog widget so you've not much choice.
If you need a quick fix, add "&& XtIsRealized(widget)" to the
outermost conditional around the block of code in AddFocusHandler().
An official patch will be forthcoming.
----------gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (02/12/90)
/ hpcvlx:comp.windows.x / swick@ATHENA.MIT.EDU (Ralph R. Swick) / 8:05 am Feb 9, 1990 /
Sorry about the spurious duplicate reply. My mail karma is low...
This bug appears to be present in the X11-R4beta release.
And in the R4 release bits, even though this code was substantially
re-worked after beta (I'll not say by whom, to protect the guilty :-(.
As the "guilty party" I tried the program and also went back over the archive
of the final stages of the R4 release when this code was being completed.
It turns out that the last sources I sent to Ralph had this bug fixed but it
got dropped on the floor during integration and some other fixes Ralph made ?.
So in this instance I'm almost innocent :-).
If you need a quick fix, add "&& XtIsRealized(widget)" to the
outermost conditional around the block of code in AddFocusHandler().
An official patch will be forthcoming.
Actualy, I think the problem is a redundant call to AddFocusHandler in
XtSetKeyboardFocus that should be conditional on the descendant being
realized, but either way I still think your code is suspect.
When I tried it with a fix in Xt, it mapped the dialog over the button
without the box trying to grow to accomadate the dialog. This is due to
the fact that you explicitly map the dialog without managing it or unmanaging
the button. This assumes that what you want is to have the dialog replace the
button in the box. if what you want is to have the dialog popup in a separate
window then you need a shell as it's parent rather than the box in the primary
hierarchy.
Gabe Beged-Dov
Interface Technology Operation
Hewlett-Packard
----------