Release 10.1A: OpenEdge Development:
Debugging and Troubleshooting

> ## Application control

> During a debugging session, the Debugger allows you to start and stop procedure execution as you want, and even execute procedures that are not part of your application. All procedures the Debugger executes are added to the procedure call stack. The procedure call stack is a last-in-first-out (LIFO) memory structure that keeps track of the execution status of each procedure as it calls a subprocedure or invokes a trigger block.

> The following sections cover:

> - Open and incremental execution

> - Procedure interruption

> - Procedure termination

> ##### Open and incremental execution

> To execute a procedure other than the one the Debugger is currently running, open the procedure and start it from the Debugger using Debug Run. Whenever the Debugger has control, you can run any application, effectively adding it to the procedure call stack of your current application. This allows you to mix and match procedures dynamically or run diagnostic procedures while debugging your application.

> Note: You cannot start a procedure that requires parameters or arguments from the Debugger. The Debugger has no way to define them.

> When the Debugger is stopped in an executing procedure, you can continue execution using Debug Continue. This allows the procedure to execute until it encounters a breakpoint, an interrupt, or the end of the procedure. You also can continue executing the current procedure line by line using Debug Step Into, Debug Step Out, or Debug Step Over. Use Debug Start Animation to watch your program execute as the Debugger steps through your code. Use the Run to Line command to continue program execution up to a specified line of 4GL code.

> ##### Procedure interruption

> To selectively interrupt procedure execution, you can set or remove breakpoints using Edit Breakpoints. A breakpoint can be a specific line in a procedure where execution stops temporarily. When the procedure reaches a breakpoint, it halts before executing the specified line and gives control to the Debugger for your next command. The easiest way to set a breakpoint is to click in the left column of the source code pane where the procedure appears.

> A breakpoint can be conditional, where evaluation of a logical expression determines whether the interruption occurs. A breakpoint can be based on encountering an error, in which case the Debugger gets control at the next executable line after the line that caused the error.

> You can set and remove breakpoints from the 4GL using the `DEBUGGER` system handle’s `SET-BREAK( )` and `CANCEL-BREAK( )` methods. This feature is helpful to control breakpoints at specific points in your code, regardless of how the surrounding code is modified, or to set breakpoints in include files that might appear in many different procedures.

> To interrupt a running procedure and give control to the Debugger, the Debugger provides a Debug Interrupt command. This interrupts a procedure wherever it is executing, as if it encountered a breakpoint. It is particularly useful when you want to interrupt a procedure in which you have not set a breakpoint.

> Note: If you use Debug Interrupt while an alert dialog box is displayed on the screen, or while the procedure is executing a `READKEY` or `PAUSE` statement, the Debugger does not take control until you dismiss the alert dialog box or satisfy the `READKEY` or `PAUSE` statement.

> You can provide a means to interrupt a running procedure from the 4GL by setting the `SESSION` system handle `DEBUG-ALERT` attribute to `TRUE`. This places a Help button on all alert boxes that provides access to a Stack Trace dialog box and the Debugger.

> ##### Procedure termination

> You can force a procedure to terminate at a break or interrupt point, using Debug Stop. This effectively inserts and executes a 4GL `STOP` statement at the current break or interrupt point.

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