Testing scripts

The quickest way to test that scripts work as expected, is to click the Preview tab at the bottom of the workspace.

You can even do this while creating a new script, either with a Script Wizard or in the expanded script editor. Click Apply at the bottom of the script editor to see the effect of the script on the Preview tab of the Designer.

Note that scripts that use values of data fields can only be effective when a data file or data mapping configuration is open. See Loading data.

Testing for errors

One way to see if a script is functional is to take a look at the Scripts pane.

Hover over the name of a script in the Scripts pane to highlight parts of the template that are affected by the script.

Icons on the name of scripts in the Scripts pane can show a warning, information or error icon.

  • The information icon (i) shows that the selector of the script does not produce a result in the current section.
  • The warning icon (!) appears, for example, when a script refers to an unknown field in the record set, or when ; is missing after a statement.
  • The error icon (x) displays when the script results in an error, for example, when it uses an undeclared variable.

If an expanded script contains errors or if there are warnings, icons appear in the overview ruler on the right hand side of the editing area. These icons are shown relative to their position in the script and do not move as you scroll down. You can click on an icon to quickly jump to the error or warning. Script errors are highlighted by a red icon, and warnings in yellow. The topmost icon will display red if any errors exist in the script at all.

Preflight

In addition to the icons and messages in the Scripts pane, a preflight can show if your scripts function as expected before generating output:

  1. On the menu, select Context > Preflight.
  2. Select All, or enter a selection of records. You can specify individual records separated by semi-colons (;) or ranges using dashes. For example: 2;4;6-10 would print pages 2, 4, 6, 7, 8, 9 and 10.
  3. Click OK.

Preflight executes the template without actually producing output. When a data mapping configuration is used, any pre- and postprocessors are run as well.
The Preflight window displays any issues once it’s done. It will tell, for example, which selectors were not encountered in the template.
Double-click a script warning/error (either in the Preflight Progress dialog or in the Preflight Result view) to open the script in the script editor. The relevant line will be highlighted.

Be aware that scripts run in a specific order (see The script flow: when scripts run). When one script unintentionally influences the results of another script, changing the order of the scripts in the Scripts pane may help (see Changing the order of execution).

Testing for speed issues

To measure the time that the execution of scripts will take:

  • On the Context menu, click Profile scripts.

Profiling means running the scripts in the template, with the current record, to see how fast scripts in the Scripts pane execute. It helps greatly in troubleshooting performance issues caused by scripts.

After running the Script Profiler you can see in which sections the script has run:

  • Hover the mouse over a value in the column Count to see the number of times that the script has run, per section.

You can also see the breakdown of the execution time across different execution stages:

  • Hover the mouse over a value in the column Elapsed to see the time elapsed (in milliseconds) since the start of the session. In the Scripts Profiler, the scripts are by default sorted based on the values in the Elapsed column, from high to low.
  • Hover the mouse over a value the column Delta to see the difference between the time elapsed (in milliseconds) in the previous session and in the current session.

The script execution stages are:

Query: the time it takes to find the selector in the template.

Looking for text is a rather lengthy operation. Use an ID (possibly in combination with a text) instead of a text selector to make the query faster. For more tips, see Optimizing scripts.

Execution: the time it takes to execute the script. If you are an experienced JavaScript coder you may be able to optimize the code to speed up the execution of the script.

Functions that actually change the content of the template (for example,append()) are comparatively time consuming. Avoid using such functions in a loop. For more tips, see Optimizing scripts.

Note that the times vary slightly per run of the Script Profiler. Run the Script Profiler a number of times and calculate an average from the results, before trying to speed up the execution of a script.

Script Profiler settings

Number of runs

By default, the Script Profiler runs on 1000 instances of all the scripts. To test on a higher or lower number of instances:

  1. On the menu, select Window > Preferences.
  2. Click Scripting.
  3. Set a number of iterations (maximum one billion) and click OK.
Sorting

In the Scripts Profiler, the scripts are by default sorted based on the values in the Elapsed column, from high to low. Click any of the columns to sort the scripts according to the values in that column.

Script timeout

When testing scripts, either by toggling to Preview mode or by using the Script Profiler, a script timeout is active in the Designer, so that scripts that need a very long time to run are stopped after a set time. You can adapt this timeout to your needs, as follows:

  1. On the menu, select Window > Preferences.
  2. Click Scripting.
  3. Set a timeout in seconds (for example: 2s) and click OK. The minimum timeout is 1 second.
The script timeout is not active when generating output.