6.11 Breakpoints

6.11.1 How breakpoints work

A breakpoint forces a pause in application execution, which we call a break. When a thread within an application attempts to execute an item of code that has a breakpoint on it, Functional Developer pauses the application and opens a debugger window on the thread that reached the breakpoint.

There are also non-pausing breakpoints that print a message in the debugger's interaction pane. Generally, when we refer to breakpoints, we mean the pausing kind.

Breakpoints can be either enabled or disabled. Enabled breakpoints are shown with a solid red octagon icon, while disabled breakpoints are shown with a hollow red octagon.

When you first set a breakpoint, it is enabled. You can disable a breakpoint if you do not want it to cause a break next time you run the application. If you decide that you never want the application to break at that point again, you can clear the breakpoint to remove it completely.

When Functional Developer encounters a breakpoint, it prints the breakpoint location in the debugger's context pane, and also (if the breakpoint option Print Message is checked) adds it to the debugger's interaction pane. See "Breakpoint options" on page 124.

Breakpoints are associated with the application's project, rather than the compiled application itself. This means breakpoints only have an effect if the application is executing under debugger control within the development environment, via Application > Start and similar commands.

When you set a breakpoint in a function that is in a used library, the breakpoint does not go into the project that owns the function, but instead into the project you are browsing--or the active project, if in the editor.