Debug Mode
WinTask does not include a debug mode as such. Below we explain what to do when compilation errors occur or when execution errors occur. For understanding execution errors, #IgnoreErrors system variable must be set up to 0 (its default value). We have also listed the compiler limits.
Compilation Errors
Incorrect Construction
If a block structure (Sub...EndSub, Function...EndFunction, If...Else...Endif, Repeat...until, While...wend) does not include the starting tag and the ending tag, compiler returns the error message "Syntax Error" plus a line number. This line number is either the line where the block ends, or the line where the new block starts.
Note that this syntax
a=0
Repeat
a=a+1
pause 1 secs
until a=10
gives a compilation error "Invalid statement Pause...until". The compiler does not know if the structure is a wait structure (pause 1 sec until...EndPause) or a loop structure. Resolve that error by inverting the last two lines within the loop:
a=0
Repeat
pause 1 secs
a=a+1
until a=10
Includes
If a compilation error occurs in a script that Includes other scripts, double-click the line number displayed in the .LST file (or in the Output window) in order to go directly to the line in the source script where the error occurred. If the compilation error is in an included script (statement Include), the line number given in the .LST refers to a line within the included script. Hence, it's easier to compile only the included script, and so good programming practice is to include only scripts that compile on their own.
Tricks
Sometimes compiler error messages are not very meaningful and when referring to the line in error, the line seems correct. In such cases, try commenting out the line in error and compile again. Then see if it's really that line which had the problem.
If the script is big, copy the part which has problems in a new script and compile only this part.
Compiler limits
For WinTask Lite:
Maximum number for procedures/functions: 100.
A script cannot contain more than 32 local variables.
A script cannot contain more than 200 variables.
A script cannot contain more than 64 arrays.
Maximum size for an array is 65535 elements (so from 0 to 65534).
Maximum number of parameters which can be passed to a procedure/function is 16.
A maximum of 5 Include levels is allowed.
For WinTask:
Maximum number for procedures/functions: 500.
A script cannot contain more than 32 local variables.
A script cannot contain more than 1000 variables.
A script cannot contain more than 128 arrays.
Maximum size for an array is 65535 elements (so from 0 to 65534).
Maximum number of parameters which can be passed to a procedure/function is 16.
A script cannot contain more than 64 OnAction.
A maximum of 5 Include levels is allowed.
Execution errors
Traces
You can trace the script execution by using techniques described below.
Log file: you can record in a .log file either all the statements executed, or only the Comment statements. Use the LogFile statement to initialize your log process; it's more flexible than configuring it through the menu item Configure/Run in WinTask Editor. Logfile statements are not available in WinTask Lite.
Customized log file: you can record the information you want in your own log file. Write your own log procedure and call it when needed:
Sub write_log(msg$)
local a$
a$=Hour$()+":"+min$()+":"+sec$()+" "+msg$
write(log_file$,a$,crlf)
EndSub
Messagebox : use the MsgBox statement to display some information or variables. Script execution stops until user validation. You can navigate within your application while the script is stopped. Note that the dialog box has the focus, and so the running of the application is slightly modified.
Messageframe : use the MsgFrame statement to display some information or variables. The screen is displayed for a short period and disappears (when RemoveFrame statement is executed) without any user validation. So the running of the application is not modified at all.
Beep : use the Beep statement in one branch of your script. If you hear the beep, then you know that that branch was executed.
Execution error because object not found
The usual execution errors such as infinite loop, overflow, ... are resolved the same way as with other programming languages. One specific execution error when running a WinTask script is "object not found" (an object can be a window, a control, a menu item).
The Execution error dialog box (which is displayed when #IgnoreErrors = 0, the default value for this system variable) shows the script name and the line number where the error occurred. If scripts are included, the line number refers to the long script with all the included scripts.
We give below tips for resolving a "window not found" error. They also apply to resolving an "object not found" error.
When you know the window where the problem occurs, three things can happen :
the expected window is not displayed or is not active
the expected window is displayed but its name has changed
the expected window is displayed too late and the error message is already there.
First case: the expected window is not displayed or is not active.
Usually, this case occurs because the application does not behave at replay the same way as when you recorded your actions: try manually performing the actions recorded in the script; if the window does not appear, modifiy the script for the new behavior of your application. If the window is displayed when you perform your actions manually, go to the second case.
Second case: the expected window is displayed but its name has changed.
Verify (using Spy) that the window name (including its instance number) is the one specified in the UseWindow statement where the error occurred. Note that you can truncate the class name of the window if this class name changes from one execution to another. You can too force #UseExact = 0. If only the instance number has changed at replay, ensure that you have not launched the application several times; note that you can force the instance number to 0 and at replay the first instance found will be used.
If the execution error still occurs, review what is happening a few lines before the UseWindow is executed: perhaps a mouse click is not being performed, characters are not being typed into the proper field, a menu option is not selected correctly, .... If any of these things are happening it is usually because replay is too fast. Insert Pause 1 statements to slow the execution in a general way, or insert synchronizations that check for specific conditions.
If you see that menu selections are not being replayed correctly, use shortcut keys instead of mouse menu selections, and use Tab for moving from one field to the next one.Third case : the expected window is displayed too late.
You can resolve that error by increasing the value of the system variable #ActionTimeout (default value is 30 seconds), or adding a Pause n secs statement, or inserting a synchronization.
Pause fails
If a Pause statement fails, verify that the value of the system variable #PauseTimeout is not too low (default value is 120 seconds). To find where the error is occurring more easily, change the PauseFalse message:
MsgBox("'Wait for' at line " + #ErrorLine$ + " has failed !",16,"Runtime error")
for a more meaningful message.