Using the graphical interface of debug

Debugging a graphics application

Debugging an X-based program with the debugger's graphical user interface may be more difficult than debugging a non-X-based application, but it is not impossible. The problem arises when an event triggers while the program being debugged has grabbed the input focus. For example, the program hits a breakpoint in any menu button callback. As long as the program being debugged has control of the mouse, you cannot use the mouse to perform any operation in the debugger.

NOTE: This problem does not arise if you have two terminals available, using one display for the debugger and the other for the program being debugged.

You can get around this problem be setting breakpoints in your menu callbacks with the following associated commands:

   set XtUngrabPointer(w,0); set XFlush(XtDisplay(w))

where w is the first argument to your callback, and must be a widget and not a gadget. Associated commands can be specified in the ``Commands'' field of the ``Stop'' popup window from the ``Event menu'' option. When the above commands are executed on entry to the callback function, an explicit ungrab of the pointer occurs, thus relinquishing exclusive control over the mouse.

If you don't want to change the behavior even slightly, you can still debug the process, because you can perform any operation in the debugger using the keyboard equivalents. For example, press <ALT/ESC> to get to the debugger's Source window, use the arrow keys to traverse the menus, and press <Return> to select a button. See the documentation for your desktop for more details on keyboard navigation.

Of course, eliminating the convenience of the mouse eliminates one of the main reasons for using the graphical interface. If you want to use the command line interface instead you may invoke the debugger by typing debug -ic in an xterm window. Even when using the command line interface, you will need to press <ALT/ESC> to get to the xterm window whenever your debugged program stops.