Progress
Debugger Guide


Nonvolatile Events

If your application uses a large number of DB and UI triggers, it might help to include DEBUGGER handle statements in the code to debug the application. Especially with UI events, the combinations of UI actions that cause them to fire are not always clear because the user has most of the control over when UI actions occur. If you also have cascading events (events firing within events, for example using the APPLY statement), the order of execution can be even harder to follow.

DEBUGGER Handle Methods

You can provide some built-in event debugging capability by invoking the SET–BREAK( ) method at the start of each trigger block. Once the Debugger is initialized, this method (with no arguments) sets a breakpoint on the first executable line after the line that invokes the SET–BREAK( ) method. This saves having to find the procedure names and line numbers for all the trigger blocks you might want to break on during a debugging session. You might also want to use the DISPLAY–MESSAGE( ) method to display data and attribute values as each trigger executes.

R-code Impacts

When the Debugger is not initialized, DEBUGGER handle statements have no functional affect and incur no more r-code performance or memory penalty than variable assignment statements. Thus, when you put your application into production, you can often leave these debugging statements in the source code without any noticeable affect on application or system performance.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095