Widget Troubleshooting

Widget Troubleshooting

This section provides troubleshooting information by discussing some common pitfalls when working with widgets.

Note: Additional debugging information is provided in "Tips for Debugging Graphics Programs".

Keyboard Input Disappears

A common problem in IRIS IM programs is that keyboard input disappears. This is caused by how IRIS IM handles keyboard focus. When a widget hierarchy has keyboard focus, only one component of the hierarchy receives the keyboard events. The keyboard input might be going to the wrong widget.

There are two solutions to this:

The easiest solution is to set the resource
keyboardFocusPolicy: POINTER
for the application. This overrides the default traversal method (explicit traversal) where you can select widgets with keyboard keys rather than the mouse so that input focus follows the pointer only. The disadvantages of this method are that it eliminates explicit traversal for users who prefer it and it forces a nondefault model.
A better solution is to set the resource
*widget.traversalOn: TRUE
where widget is the name of the widget, and to call

XmProcessTraversal(widget, XmTRAVERSE_CURRENT);
whenever mouse button 1 is pressed in the widget. Turning process traversal on causes the window to respond to traversal (it normally does not), and calling XmProcessTraversal() actually traverses into the widget when appropriate.

Inheritance Issues

In Xt, shell widgets, which include top-level windows, popup windows, and menus,

inherit their colormap and depth from their parent widget
inherit their visual from the parent window

If the visual does not match the colormap and depth, this leads to a BadMatch X protocol error.

In a typical IRIS IM program, everything runs in the default visual, and the inheritance from two different places does not cause problems. However, when a program uses both OpenGL and IRIS IM, it requires multiple visuals, and you have to be careful. Whenever you create a shell widget as a child of a widget in a non-default visual, specify pixel depth, colormap, and visual for that widget explicitly. This happens with menus or popup windows that are children of OpenGL widgets. See "Using Popup Menus With the GLwMDrawingArea Widget".

If you do get a BadMatch error, follow these steps to determine its cause:

Run the application under a C debugger, such as dbx or cvd (the Case Vision debugger) with the -sync flag.
The -sync flag tells Xt to call XSynchronize(), forcing all calls to be made synchronously. If your program is not Xt-based, or if you aren't using standard argument parsing, call XSynchronize(display, TRUE) directly inside your program.
Using the debugger, set a breakpoint in exit() and run the program.
When the program fails, you have a stack trace you can use to determine the problem.

Note: If you don't use the -sync option, the stack dump on failure is meaningless: X batches multiple requests and the error is delayed.