In Dashboard Architect, setting breakpoints makes debugging easier than the two traditional approaches.
Breakpoints are required when one or more areas of code come under suspicion. The cursor is positioned on a strategic line and a breakpoint is inserted by clicking 
or F9.
Internally, a breakpoint is implemented as a set of additional dynamic instrumentation instructions alongside the regular JavaScript. As a breakpoint is extra JavaScript, it behaves just like other code changes. If it is placed inside declarative code such as a function, you must click 
so the breakpoint can become part of the declaration for the function.
When all breakpoints are set, move to instrumented.bqy, and activate the event (for example, clicking a button). The code is executed and at some point it encounters the breakpoint. The instrumented.bqy calls the Debug Server and requests that execution is suspended and highlights the line associated with the breakpoint.
The Debug Server keeps Interactive Reporting Studio suspended and hands control to the user interface of Dashboard Architect, so the execution state of the application can be examined. The evaluate pane in the output window is activated, and JavaScript expressions can be entered for evaluation.
To see the value of a local variable, enter the name of the variable, and click 
. To see the value of an Interactive Reporting Studio property, enter it into the evaluate pane. As a shortcut, highlight text in the editing window, right-click, and click Evaluate, or copy and paste the text into the evaluate pane and modify the expression as required. To clear the evaluate pane, click 
.
If incorrect syntax is entered, the JavaScript engine generates a syntax error and aborts the current thread of execution. Return to instrumented.bqy and recommence the test by clicking the control to reactivate the breakpoint.
Limitations exist as to where breakpoints can be placed in code. Breakpoints are implemented, as JavaScript is inserted, so they must be syntactically valid. Dashboard Architect does not have direct access to the JavaScript engine and therefore cannot guarantee the correctness of breakpoints. These guidelines help with writing code that is straightforward to maintain, read, and set breakpoints upon.
Table 20. Breakpoints Working With JavaScript
JavaScript | Comment |
|---|---|
Line 01 function f(param){ | Break occurs when the function is being parsed, not when it is called |
Line 02 var x | |
Line 03 if (condition){ | |
Line 04 statement_1 | |
Line 05 }else{ | |
Line 06 statement_2 | |
Line 07 } | |
Line 08 switch (x){ | |
Line 09 case 1: | Breakpoint is not OK as nothing can come before case |
Line 10 statement_3 | |
Line 11 break | |
Line 12 case 2: | Breakpoint is not OK as nothing can come before case |
Line 13 statement_4 | |
Line 14 break | |
Line 15 default: | Breakpoint is not OK as nothing can come before default |
Line 16 } | |
Line 17 // comment | |
Line 18 } |
As seen in Table 20, only a few distinct and recognizable places exist where a breakpoint cannot be placed. If the code is not written in this manner, the options for breakpoints are restricted. Examples are provided in Table 21.
Table 21. Areas Where Breakpoints Do Not Work With JavaScript
JavaScript | Comment |
|---|---|
Line 01 function f(param){ | |
Line 02 var x | |
Line 03 if (condition) | |
Line 04 {statement_1} | Breakpoint is not OK |
Line 05 else | Breakpoint is not OK |
Line 06 {statement_2} | Breakpoint is not OK |
Line 07 switch (x){ | |
Line 08 case 1: statement_3;break | Breakpoint is not OK |
Line 09 case 2: statement_3;break | Breakpoint is not OK |
Line 10 default: | Breakpoint is not OK |
Line 11 } | |
Line 12 // comment | |
Line 13 } |