With each breakpoint, you can associate a sequence of Debugger commands to be performed each time the breakpoint is reached. You can also specify whether you want the prototype execution to pause after performing these commands, or to continue. To define the command associated with the breakpoint, use the DO clause when setting the breakpoint:
The DO clause can contain any sequence of Debugger commands separated by semicolons.
For example, each time event
e1
occurs, you want to stop and check the current values of conditions and data-items. Instead of retyping in the same commands on each arrival of the breakpoint, you enter them only once when defining the breakpoint:Immediately upon reaching the breakpoint, the Debugger suspends the execution and displays the requested values:
It then places the debugging prototype into debug mode. After examining the values, you may perform more Debugger commands.
If you want to perform the DO clause without suspension of the execution, you put GO as the last command in the DO sequence.
differs from the previous one in that the execution is not stopped after displaying the values. You would not be able to enter more commands at breakpoint
bp_1
.If in a DO clause, the GO is followed by other commands, they are ignored by the Debugger.
DO clauses can, themselves, set breakpoints. This may result in nesting of DO clauses, as follows:
There are no restrictions on the depth of nesting.
A breakpoint can be reached only after the end of the step in which its trigger occurred. This is also the point where the DO clause is initiated. At this time, all that occurred during the last step is available in the DO clause.
At each step, all breakpoints are checked according to the alphabetical order of their labels. Consider, for example, triggers of two breakpoints named a and b which occurred in the same step. If the first has a GO command in its DO clause, the second breakpoint is not reached.