JavaScript errors can be difficult to locate, especially in complex scripts. This article will cover a few simple methods to start trying to find and resolve some common errors.
Scenario: The script page freezes on load, and you have to close the window manually.
Bug: A Calculate Field has been created with an additional trailing bracket, and this bad code is executed on page load.
[Text Box 1] = [Text Box 2]];
This could be caused by a number of things, but a few JavaScript errors are more likely than others: having an additional or missing bracket, missing a semicolon at the end of a line where it's required, or having a mis-spelled control name called in code. When JavaScript encounters a major error, it ceases executing for the rest of the page - typically stopping CallScripter itself from running properly too.
Developer Tools
The Developer Tools won't always provide the actual error that's caused the failure (or even the correct line, due to the way that the code is executed!), but it can help you locate roughly where the error is likely to occur.
Your browser's Developer Tools are typically accessed by pressing F12, and this should be done when on the broken script page. Upon doing so, a window will pop up showing any errors or alerts for the page.
Note that the errors in the following examples manifest differently between Chrome and IE:
Chrome Developer Tools:
In Chrome, this particular error displays the "Unexpected token ]" error at the bottom of the window. By clicking the link at the right-side of the error entry (script.aspx:77), it takes us to the relevant line of code - in the central window, you can see that "F202.value = F203.value];". The "F###.value" refers to a field in CallScripter, and you can see that there's a square bracket at the end of this statement. Deleting this additional square bracket will fix this error, and allow the page to execute as expected on the next run.
Internet Explorer Developer Tools:
In Internet Explorer, this error instead displays as the "Expected ';'" error, which isn't as immediately obvious as the cause of the problem. By clicking the link below the entry ( script.aspx (166,22) ), we get taken to another view that shows where it thinks the error has occurred.
In this case, the displayed line looks very similar to the Chrome example - we can see a "F57.value = F58.value];" line has been marked. Similarly, deleting this additional square bracket will fix this error, and allow the page to execute as expected on the next run.
Comment-Searching for Bugs
If the Developer Tools haven't helped you pinpoint the error, an alternative method is to disable blocks of code on the page to find when the error stops appearing.
If this page had 3 Calculate Fields on it, we would start by commenting out the entire codeblock on the first and checking it. If the error still appeared, we would comment out the second, and so on.
Eventually, we'd comment out the Calculate Field that had the problem block, and the script wouldn't throw the error anymore:
We can then step through the block of code to find which section has caused the error, testing the script each time we uncomment a section.
This would still work without error, so we would uncomment the next block:
This would now throw the error on script run. To confirm it really is something in that section, we would then comment out solely that section and see if the script ran without error:
Having confirmed that this was the section with the error, we could start stepping through element by element to find the error. Luckily for us, the error is in the first line of the section:
Having identified the problematic line of code in the page, the process of working out what the actual JavaScript error is should be far easier.
Other Resources
W3 Schools have a good
JavaScript guide for beginners and intermediate coders, including practical examples and test environments for experimentation in.
JS Lint is a website that helps make your code neat and efficient, and looks for any errors or potential mistakes. Be aware that it's not directly transferrable from CallScripter coding due to the way that Fields are wrapped, but if you replaced your
[Field Names] with
dummyVariables it can be a useful helper. Note that Lint has been implemented directly into Synergy's code editor interface, so any errors should be flagged up next to the line number in the code editor window.