- Browser On / Off
This toggle enables the browser to remain active when debugging. The browser evolves at the same time as the CSS (modification, add,...) and it is then possible to locate break points directly on the icons with the 1st mouse button. The corresponding icon is highlighted in RED. This is a GRAPHIC (GRA) break point which will be active during a redraw. If a modification had been performed when debugging the CSS, the browser will take this into account and will redraw itself (watch out for the performance). During a redraw, an arrow follows the progression of the debug operation.
This toggle traces all PHIGS calls carried out (trace mode for a traditional debugger). PHIGS calls will be viewed in the display zone.
- Output Calls
This toggle generates calls to PHIGS functions in a call file. On activation/inactivation, the opening is performed in APPEND.
- Output Warning
This toggle generates warnings that may be detected by the debugger in a file (Opening in APPEND)
- State Value
Controls the display of system states (PHIGS, Workstation, Structure, Archive)
- Graphic Context
This toggle displays all graphics parameters valid during running.
(current active line type, active font number, current active edge width ,...)
(For purists : The traversal state list)
A D preceeding the line indicates that it is the default value
An M preceeding the line indicates that the value has been modified in relation to the default value
A P preceeding the line indicates that the value has been modified in relation to the previous step
These lines are highlighted in reverse video.
In the example : PELEM_VIEW_IND.
- Display Warning
This toggle controls the display of warnings in the trace area
WARNING this button generates a core dump on confirmation, representing the end of the process. It is used to explore the stack of application calls at a given moment in the application thanks to a traditional debugger.
A problem is identified in a program that particularly makes PHIGS calls. With PHIGS debugger, the defective instruction is identified (defective due to poor allocation of memory, inopportune freeing of the application, ...) by generating a core just before, and by re-reading this core with a traditional debugger (dbx, xdb, ...) the call stack may be viewed (where, trace, stack, ...)