Try OpenEdge Now
skip to main content
Online Help
Running and debugging ABL programs : Concepts : Progress Developer Studio for OpenEdge Debugger : Debugging operations : Options for controlling program execution : Code-stepping
Code-stepping refers to a set of commands that let you run procedures incrementally, suspending the process as each statement or block is executed so that you can evaluate the precise effect of each code segment. Used in conjunction with breakpoints, code-stepping commands let you fully control when the application runs uninterrupted and when it is suspended.

Code-stepping options

The following options are available:
*Step Into - Causes the Debugger to execute the current line and continue until it reaches the next executable statement, which may be in the current procedure, a subprocedure, or a trigger. That statement becomes the current line, and is not executed until you continue.
*Step Over - Causes the Debugger to execute the current line and continue until it reaches either a breakpoint, or the next executable statement in the same procedure. Thus, if the current line calls a subprocedure or causes a trigger to execute, the subprocedure or trigger is executed without interruption unless there is a breakpoint. In other words, the Debugger steps "over," not "into," the subprocedure or trigger.
*Step Return - Causes the Debugger to execute the current line and continue either until it reaches a breakpoint, or until the current procedure ends and returns control to the calling procedure.
*Resume - Causes the Debugger to execute the current line and continue without interruption until it reaches either a breakpoint or the end of the program.
*Suspend - Interrupts execution and gives control to the Debugger. Also, suspends an attached AVM.
*Terminate - Interrupts execution and ends the Debugger session.
*Disconnect - Disconnects the Debugger from the attached AVM.

Garbage collection in Debugger

The OpenEdge client uses a feature known as garbage collection. Garbage collection refers to the automatic deletion of ABL objects that have no current reference. Since the objects are no longer being used, removing them frees up resources and relieves you of having to explicitly delete each object created during a session.
With regard to the Debugger, garbage collection proceeds as follows:
*If an object is garbage-collected at the end of a statement, the debugger does not step into the destructor for the object (if the object has a destructor) unless there is a breakpoint in the destructor.
*The DELETE OBJECT statement steps into the destructor whether or not it contains a breakpoint.
*When stepping over a statement (as opposed to stepping into a statement), the Debugger stops in the destructor only if it contains a breakpoint, whether the object is deleted due to garbage collection or as the result of executing the DELETE OBJECT statement.