Breakpoints and Data Breakpoints

Use breakpoints to test and debug programs by pausing thread execution so that the status of the application can be examined. 

Breakpoints (and watches) can be saved from one debugging session to another using the Save Workspace and Open Workspace buttons. Breakpoints can be temporarily disabled without being removed by toggling the Disable tool in the toolbar, (Ctrl + F9)

There are two types of breakpoints that are referred to throughout this document:

Breakpoint:

The word "breakpoint" used by itself means a code breakpoint. This is a programmer-defined break in code that when reached, triggers a temporary halt. See: Set and Clear Breakpoints

Data breakpoint:

A data breakpoint is set on a variable and triggers a break when the value is first set or when it is changed. See: Set Data Breakpoints

What happens when a breakpoint is hit:

Your application will run at full speed until a statement that contains a breakpoint is about to be executed. At that point, execution of the thread that is attempting to execute the statement containing the breakpoint will be suspended. A detail line will be added to the breakpoint tab of the action window, identifying the thread that has been suspended and the breakpoint that was hit. The breakpoint tab will be forced to the front of the action window, the tab containing the source code with the breakpoint will be forced to the front of the code display window, and the Source Debugger window itself will be made the active window. Additionally, the module trees will automatically be refreshed and positioned at the module instance that contains the breakpoint. This means that you can see a "snapshot" state of the module trees at the time that the breakpoint was encountered. A yellow arrow will be displayed beside the breakpoint that was hit.

If your application uses multiple threads, it is possible for different threads to execute a given statement.

What happens to other threads when a breakpoint is hit:

Note that only the thread that executes a statement containing a breakpoint will be suspended. Other threads within VTScada, including those within your application, will continue to run normally. If this were not the case, you wouldn't be able to use the Source Debugger. This means that while one thread is paused on a breakpoint, another thread may attempt to execute the same statement and cause another breakpoint. This would result in exactly the same sequence of events, with a second entry showing a hit breakpoint being made in the breakpoints tab of the action window. This might happen if a breakpoint is placed in a subroutine that can be called by modules running on different threads.

While a thread is paused at a breakpoint, you may navigate to any module in any of the module trees that you wish and examine or modify the contents of any data variable. In other words, suspension of execution of a thread affords you the time to examine the state of things at a given point in the execution of your application. This can be most useful in detecting transitional states that would otherwise be difficult to find.

Continue execution past a breakpoint:

To continue execution past a breakpoint, ensure that the breakpoint from which you wish to continue is selected in the breakpoints tab of the action window, then use any of the following. If multiple breakpoints are hit, only the thread for the selected breakpoint will be continued.

  • Continue tool (F5). Execution will continue normally.
  • Step Into tool (F11). If the breakpoint was set on a subroutine call, that module will open and execution will advance by one statement.
  • Step Out tool (Shift+F11). Run the remainder of the subroutine at full speed and break on the next statement in the current thread after the subroutine's Return statement executes. The "next statement" may be the script statement following the subroutine call, the next steady-state statement to be evaluated on the same thread, or the first statement of the freshly constructed module instance if stepping out of a constructor.
  • Step Over tool (F10). Execution will advance by one statement within the current module. If the next statement is a subroutine call, execution will proceed through that module without pause.
    Note that more than one statement might be written on a single line, as is sometimes the case with IfThen, IfElse, WhileLoop, DoLoop, Case, or an Execute clause. In this case, the step will advance through the statements without leaving the current line.
  • Run to Cursor tool (F12). To use this, you must first select a statement in the code display window other than where the breakpoint is set. Execution will continue to the selected statement then pause again.

Breakpoints in critical sections:

A breakpoint can be placed on any source code line including critical sections. When a breakpoint is hit within a critical section, the critical section is effectively released, then re-acquired when you continue execution. Depending on the code contained within the CriticalSection, this may cause behavioral differences within your application.