Using Breakpoints in the Debugger

Breakpoints interrupt execution of your code. The debugger stops before executing a line of code that contains a breakpoint.

Include breakpoints at important points in your code so that you can observe the flow of code or determine the values of variables at a specific point in your code.

Breakpoints are invalid for blank lines, lines that contain only comments, and end instruction lines.

You can set breakpoints, including conditional breakpoints, from the Debugger window or from the Jade Platform development environment.

For details about enabling or disabling breakpoints, see "Using Conditional Breakpoints and Pass Counts", later in this chapter.

You can set breakpoints in any Jade method.

After re-compiling a method while using the Jade debugger, the debugger continues to display the old method source under the following circumstances.

The application is displaying a modal form.
The debugger next stops on a breakpoint in the same method that was compiled and that method was the last displayed by the debugger.

When the debugger is at a breakpoint:

If nothing is selected and you hover the mouse over a variable, the value of the variable is displayed when possible (including path expressions). No methods are executed.
If an expression is selected, hovering over the selection attempts to execute the expression. The expression must be compilable within the context of the method and must return a value.

If the compile and execution succeed, the returned value is displayed.

It is your responsibility for the effects that the expression may have on the database and execution of the method logic.

In the Breakpoints window:

When an enabled breakpoint is set on a line, a red circle is displayed in the breakpoint margin.
When a disabled breakpoint is set on a line, a white circle is displayed in the breakpoint margin.
Clicking on an empty breakpoint margin for a line sets a breakpoint.
Clicking on a disabled breakpoint (indicated by a white circle) enables the breakpoint.
Clicking on an enabled breakpoint (indicated by a red circle) removes the breakpoint.
Right‑clicking in the breakpoint margin displays a breakpoint menu that has the following commands.
- Clear All Breakpoints From Method.
- Breakpoint Options, which initiates the Breakpoint Options dialog that allows you to disable or enable a breakpoint, set a pass count, and set a conditional expression for the breakpoint.
- Disable or Enable, which toggles the disabled or enabled status of the current breakpoint.
- Remove Breakpoint.
The Disable Breakpoint or Enable Breakpoint and the Breakpoint Options commands are disabled if the method has been changed and not compiled or if there is no breakpoint on that line.
The Breakpoint Options dialog provides a large Condition text box that allows for multiple‑line input. The dialog can also be resized.

The Condition text box provides AutoComplete functionality.

When the debugger stops on a breakpoint and the Jade Debugger Breakpoints window is displayed, the breakpoint is selected in the Debugger Breakpoints window.

Any selection in the Jade Debugger Breakpoints window is cleared if the halt was for any reason; for example, a step into or step over action.

A breakpoint always shows an icon in the breakpoint column of the user method in the Jade Debugger method source window.

When the application has stopped on a breakpoint and the Continue action is performed, the debugger clears the debugger displays, including the last method shown when the execution stack becomes empty.

If a modal form is displayed, the execution stack does not become empty and the debugger displays are not cleared.

If the next breakpoint encountered is in the same method, the debugger retains the currently displayed method.

When the application becomes idle and a modal form is displayed, the debugger clears the debugger displays and the new method source is displayed when a breakpoint is next encountered in that method.

If the method is changed and re‑compiled while the debugger has stopped on a breakpoint in that method (or in another method while that method is on the call stack), the interpreter will not reload that method logic until all copies of the method execution have exited from that method.

The debugger continues to display the old source while breakpoints are only encountered in that method until the application execution again becomes idle.

After a breakpoint is encountered in any other method, any breakpoint subsequently encountered in the changed method displays the new source, regardless of whether the old or new version of the method is being executed.

For more details, see the following subsections.