If it is used carelessly this can cause problems which range from mild to severe.
Yesterday I was using the debugger to test a new script. It was parsing JSON pulled in from an API. When I ran the script without the data viewer open, it populated the records. When I ran the script with the data viewer it threw up JSON evaluation errors.
The Data Viewer can over-ride variables defined in scripts and layouts. This allows us to inject data into running scripts, layout level evaluations, and menus. It's a powerful tool.
In this case, I did not want to inject the data. It was happening because I had left calculations in the data viewer. The data viewer contained LET expressions that defined local variables with names that were the same as the local variables defined in the script. When the data viewer was open and active it triggered the calculation of the variables. The new value overrides the values set in the script and because the new data was not valid JSON, the JSON parsing steps would generate errors.
Don't run scripts with the Data Viewer open.
Remove your tests from the Data Viewer.
Don't think of it as a library of code snippets.
Treat your data viewer like a scratch-pad.
Use it for immediate tests, and even then, use it with caution
Comment your tests
If you want to preserve your test code, wrap it in C style comments.
/* Let ( $msg ="like this" ; $msg ) */
There are gotchas for you too
- Watched variables are not always evaluated.
- When your watched variable list is long enough that variables are not visible in the window they may not be evaluated.
- This could cause your test to fail because the over-ride values you specify have not been brought into scope.
- Scrolling through your watched variables to bring them into view will normally trigger the evaluation.
Here's a file that you can use for testing.
OverrideDataVariable.fmp12 (260 KB)