Debugging and Error Trapping

Script Examples

· Script Example Format

· Automated Downloads

· Automated Login

· Connection Management

· Data Tables

· Dialog Boxes

· Dynamic Data Exchange (DDE)

· Event Monitoring

· GUI Customization

· Printing

· Program Flow

· Screen Scraping

· Session Manager

Project:   In the course of developing a complex script, the script hangs and doesn’t finish the whole sequence of steps. The Script developer would like to find out if there is an endless loop, or a command that did not execute, or some other problem in the script causing it to work improperly.

Algorithm:   Since the developer does not know exactly where the problem occurs, the DEBUG command can be used to display the commands executed. That will give a quick indication if it is an endless loop, or if the script is waiting at a particular command. Depending on the size of the project and isolation of the problem, the DEBUG output can be written to a file or displayed in a separate window, and run in step mode or continually. If the Script developer was testing a suspect command which would fail but not hold up the script, then checking the value of the ERROR( ) function and RESULT( ) function would be the best approach.

Product used in this example:  DynaComm Connectivity Series® 9. (release 9.0.0.0)

Relevant Commands and Functions:

DEBUG — Writes script commands to file or display as they are executed
SHOW — Resumes command audit initiated by DEBUG command
NOSHOW — Suspends debug mode initiated by DEBUG command
ERROR( ) — Indicates whether an error occured in execution
RESULT( ) — Returns contents of the RESULT string
EOF( ) — Indicates if end of table has been reached
WHEN ERROR — Activates when an execution error is encountered.
*SYSTEM 0x00FF — Available in some products, writes a message to a Debug window

A Brief Example:

; Script commands that are suspected to have problems
DEBUG "?"
SHOW
$var1 = "hello"
$var2 = "goodbye"
perform DisplayStrVar($var1)
$var3 = "all done"
NOSHOW
CANCEL

By specifying an output filename of "?", this example uses the Debugger in Step Mode, which means that each command is displayed before it is executed, and the developer chooses Resume to continue. The SHOW command is placed in the script where the Debugging should start, and NOSHOW can be used to turn it back off. In this example, we also make use of a special SYSTEM command that writes a message to the Script Messages section of the debug window to display the value of a variable. Note that this command only works if a Debug window is displayed at the time it is executed. An alternate way to reporting variable values is to use a utility routine like:

*DisplayStrVar($value)
DIALOG "DisplayStrVar"
MESSAGE $value
BUTTON "OK" RESUME
DIALOG END
WAIT RESUME
DIALOG CANCEL
RETURN

which allows you to read a value, click on OK, and continue the script.

Further development:

• Always evaluate the ERROR( ), EOF( ), or RESULT( ) functions immediately following the command which may fail. If there are intervening commands, the error function will return to False.
• The DEBUG command makes the task file much larger, so if you run into the limit of 64K (in earlier products) use the SHOW and NOSHOW commands to only use the Debugger when necessary.
• If a problem does not happen when running DEBUG in Step Mode, it is likely to be a timing issue which is corrected by the extra delay in the script necessary for the developer to click Resume.
• A list of Task Errors and their associated cause is available. The most current list is available in the online documentation for DCSeries, but the numbers are mostly the same for other DynaComm products.