Once the Debugger is activated and attached to a session, a break event must occur to cause the debug trace and associated data display to begin. Break events include (but are not limited to) the following:

• An error occurs that would cause object execution to be terminated
• A previously set Breakpoint is reached during processing
• The record is read when the Break on Record ChangesBreak Rule is active
• The Break icon in the Running Code group is clicked in the ribbon of the View - Debugger page
• A Breakpoint Condition, which has been set in the Breakpoints group in the ribbon of the View -Debugger page, is satisfied during processing

Of the preceding events, the two most common methods of starting up a debug trace are the first two, an error or reaching a previously set breakpoint. If, for example, an error condition is discovered in an operating object, the debugging process can be initiated by:

• Activating the debugger
• Attaching the debugger session to the session where the error will occur
• Running the process where the error occurs

When the error occurs, the page parts (Code, Watches, and Call Stack) in the debug window will be populated, and we can proceed to investigate variable values, review code, and so forth.

Breakpoints are stopping points in an object that was set by the developer. Breakpoints can be set in a variety of ways, including in the Development Environment, in the View-Debugger Code page, and in the Edit - Debugger Breakpoint List.

While the latter two locations to set breakpoints may be very useful while we are in the middle of a debugging session, those breakpoints only display while the Debugger is active. Once we exit the debugging session, those breakpoints that were set in the Debugger will disappear from view, while the breakpoints that were set from within the applicable C/SIDE Designer will remain visible and available for use until removed by a developer.

The result may be somewhat confusing because we can only see all of the breakpoints when we are in the Debugger. If we try to set a breakpoint in the Development Environment and a breakpoint has already been set on that line of code while in the Debugger, we will get the following error message:

For this reason, it may be a better practice to set all our planned testing breakpoints in the Development Environment. When we set breakpoints within the Debugger, we should clear them before ending our test session. Otherwise, we may later run into breakpoints we didn't remember existed and that we can't see in the Designers.

Active breakpoints are represented in code by a filled-in circle. Disabled breakpoints are represented by an empty circle. Examples are shown in the following code screenshot: