Setting breakpoints

You can set three different types of breakpoints:

At Line - suspends execution at a specific point in the code. Optionally, you can define a condition that must be satisfied in order for the breakpoint to be honored.
On Error - suspends execution when the program encounters an error condition. You can make the breakpoint apply to all errors, only to unsuppressed errors, or only to a single error condition that you specify.
Watchpoint - suspends execution when the value of a given variable, buffer field, object attribute, or object reference changes. Optionally, you can define a condition that must be satisfied in order for the breakpoint to be honored.

Breakpoints in ABL files outside workspace

When you use the Attachable Debugger, the source code for the program being debugged on the external AVM is located outside the Progress Developer Studio for OpenEdge workspace. To debug the file on the attached AVM, you must set a breakpoint in that file before it is executed by the AVM. You can add or remove breakpoints during debugging. The attached AVM notifies Progress Developer Studio for OpenEdge only if a breakpoint is reached.

Note: To set a breakpoint in the file outside the Progress Developer Studio for OpenEdge workspace, you must have access to its source code.

When Progress Developer Studio for OpenEdge receives a breakpoint hit notification from the attached AVM, it performs a source lookup for the notified file name. If it finds a matching file, it opens the file the in ABL Editor for debugging. If it does not find the file name, it notifies you accordingly and prompts you to edit the source lookup path. For more information, see Edit Source Lookup Path dialog.

Note: The breakpoints in files outside the workspace appear only in the Breakpoints view. The Breakpoint marker (a small blue circle (

) in the vertical rulers section on the left) does not appear for these breakpoints due to a limitation in Eclipse.

Breakpoints in an AppServer or a WebSpeed debug session

When you set a breakpoint on a line of ABL code while debugging an AppServer or a WebSpeed instance, the Debugger adds the breakpoint to all of the AppServer or WebSpeed agents. When any of these agents reaches the breakpoint, it notifies the debugger of its current state, through the broker. Upon receiving the notification, Progress Developer Studio for OpenEdge verifies if the source file and the code being executed are the same. If the file within the Progress Developer Studio for OpenEdge environment is the same as that in the AppServer or WebSpeed agent session, then the file opens up in the ABL Editor with the breakpoint hit line highlighted. The Debug view updates itself to display the agent on which the file is being executed.

Setting breakpoints programmatically

You can use the SET-BREAK and CANCEL-BREAK methods in ABL code to insert and remove breakpoints programmatically. However, the DEBUG and INITIATE methods, as well as the VISIBLE attribute, are ignored for Progress Developer Studio for OpenEdge Debugger sessions. 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

Breakpoints and include files

Progress Developer Studio for OpenEdge allows you to set breakpoints in include files that might appear in many different procedures. During remote debugging, the external AVM notifies Progress Developer Studio for OpenEdge of a breakpoint hit in an include file while executing a program that contains the include file. You can also set breakpoints in include files in a program launched from within Progress Developer Studio for OpenEdge, while debugging a local AVM.