La interfaz de VDS Renaissance está disponible en varios idiomas. La documentación oficial se mantiene en inglés para garantizar una referencia única, coherente y siempre actualizada.

Debugging Scripts

When a script does not behave as expected it can sometimes be difficult to work out why. Writing programs is never easy, but Visual DialogScript comes with a set of tools that makes it as easy as possible to work out what is going wrong.

Start by resetting the program (menu Run / Reset) so that you start running from the beginning. Then step through your script a line at a time using the Single Step button or the F8 key. Open the Debug Window so that you can see the result of all the variables used by your script after each line has been executed. This is usually enough to work out what the problem is, if you think after each line about what the correct values are supposed to be.

Sometimes a command will not work, and will report that it does not work by setting the OK indicator to false, rather than by halting with an error message. The script language does this to give you a chance to cope with the error within your script, rather than have a user presented with a cryptic error code. However, if you don't use the @OK function to test the result of OK, but just assume the command or function will work, a script will not work correctly if the command fails. You can check the status of OK at any time during debugging as it is shown in the status bar of the debug window.

A common source of problems is failure to get information from files. This is usually caused by path problems. If you only specify a filename and not a full path, the script will look in the current directory for the file. The current directory is not necessarily the directory in which the script program resides. You should always specify a full path when referencing any file. If the file belongs to the script and will always be kept in the same directory use @PATH(%0) to get the directory of the script program.

Run-time errors

Errors that occur at run-time when a script is run on another computer can be hard to debug, because you cannot run the script in the IDE to see what is happening. You only know the error code and the line number of the error. If the program contains #INCLUDE files, it is a good idea to create a map file when compiling the program, as this will help you to identify the actual line of code where the error occurred.

In difficult cases you can compile a special version of the program that includes TRACE commands, to generate a trace listing that you can analyze to see what the script was doing. If you don't want to create a special version, you could build the TRACE commands into the program, and enable them using a command line option or registry value.