Unlike other programming languages, the syntax of DialogScript is very simple. Each command occupies one line, and has a plain English name that clearly describes its purpose. Variables are typeless, and can hold many kinds of information, for example, numbers or text. Functions are clearly distinguishable with names that start with '@', just like a spreadsheet.
The DialogScript language has a simple syntax not unlike MS-DOS batch language. It is designed for ease of use and efficiency when being interpreted by the run-time engine. There are 10 system variables, %0 to %9, which initially have the script file name in %0 and command line parameters in %1 through %9, just as in a batch file. There are also a further 26 user variables, %A to %Z. The contents of all variables (including system ones) can be changed once the script is running. There are now also 4032 global variables. These variables begin with %%, a letter, then alphanumerics plus underscores (e.g. %%my_variable_1.) There is no limit on the length of these user-defined variable names.Read more...
Script programs can be tested instantly using the development environment. You can then create an executable file [not in the demo version] which can be run just like any other Windows application. Executable files created by Visual DialogScript, and its required run-time files, may be distributed free of any royalties. If you're creating programs for Internet distribution then note that the Visual DialogScript run-time files are smaller than those of any other comparable development system.
Using Visual DialogScript you can create programs that run entirely silently, in the background, programs that use a console window, and Windows programs that have a graphical user interface (GUI.) Most GUI DialogScript programs have a fixed-size main window or dialog (hence the name) but with a little extra code you can create programs whose windows are resizable.
The user interface of a GUI program is created using DialogScript code. You can write this code yourself, or use the Dialog Designer to design the program interface visually (this explains the visual part of the name.) When you're done with the Dialog Designer, it generates the code to create your design. And as long as you don't manually change this code too much, you can always use the Dialog Designer to edit it.Read more...
Dialog elements are things like buttons, input boxes and list boxes that are placed on a window or dialog and allow the user to receive information and interact with a script program. They are created using DIALOG ADD commands. Parameters to these commands specify the type of dialog element, its name (which is used to refer to the dialog element in the program) and the information needed to create the element, such as its position and size.
The < name> parameter is mandatory. Most dialog elements also require at least the top and left position co-ordinates to be specified. Many of the remaining parameters are optional, and may be left as null or omitted; when omitted, DialogScript will use suitable defaults. Position co-ordinates are relative to the client area of the dialog window.
Most dialog elements have parameters, which are appended to element name. The parameters are separated by commas. The < name> parameter, where required, is mandatory and is used to identify the individual dialog element. Most of the remaining parameters are optional, and may be left as null or omitted; when omitted, DialogScript will use suitable defaults. With most dialog elements you will usually want to specify at least the top and left position co-ordinates. Position co-ordinates are relative to the client area of the dialog window.Read more...
Unlike labels, commands need not start in the first character position. It is recommended that they are indented using spaces for readability. Commands are built into the DialogScript language, or may be added using extensions. DialogScript 5 also allows user defined commands.
A command consists of the command name (see Command Reference) followed optionally by a string. The string is used as the argument (or parameters) to the command. Many commands have only a single argument, but others have more than one, in which case commas are used to separate the parameters. A space must separate the command from the first parameter. Commands are not case-sensitive.
Here are some examples of commands:
TITLE My first script
INIFILE WRITE,Reg_Info,UserName,Fred Bloggs
Strings may include variable and function references, which are evaluated before the command is carried out.Read more...
DialogScript contains a over 100 functions, (see Function Reference) which are evaluated at run time and return a string containing information. Extra functions may be added by means of extensions. DialogScript 5 also allows user user defined functions.
Functions start with an @ symbol followed by the function name. The argument(s) to the function are in the form of a string enclosed in parentheses. The parentheses must be present even if the function takes no arguments. For functions that take more than one argument the arguments are separated by commas.
Here are some examples of functions:
%A = @ASK(Do you want to continue?)
%A = @EQUAL(%F,WIN.INI)
Note that because the @ symbol is used to identify functions you cannot use it for any other purpose (such as in text) unless it is enclosed within double quotes.Read more...
CompilerHere is a list of the compiler directives available in Visual DialogScript:
- #DEFINE COMMAND declares all command names that are not built in to VDS.
- #DEFINE FUNCTION declares all command and function names that are not built in to VDS.
- #RESOURCE ADD, ANIICON add a aniicon resource.
- #RESOURCE ADD, BITMAP add a bitmap resource.
- #RESOURCE ADD, CURSOR add a cursor resource.
- #RESOURCE ADD, ICON add a icon resource.
- #RESOURCE ADD, TEXT add a text resource.
- #RESOURCE ADD, add a user defined type of resource.
- #INCLUDE directive allows a program to incorporate code from multiple script files.
Here is a list of the compiler directives available in Visual DialogScript:
The #DEFINE directive declares all command and function names that are not built in to VDS.
This includes all commands and functions provided by extension DLLs, as well as commands and functions written in VDS code.
Note that the '@' symbol does not form part of the function name, so a function that was used as @prime(...) would be defined as: #DEFINE FUNCTION, PRIME
The #INCLUDE directive allows a program to incorporate code from multiple script files, which are compiled into the program in the order in which they are specified.
The use of .dsc in the filenames is optional. If a full path is not specified, the compiler looks first in the project's main directory, and then in a special include folder that can be set using the IDE Options menu.
The #INCLUDE directive is also used to include precompiled units (.dsu files) in a script. In this case, the file type (.dsu) must be specified in the filename, so that the compiler knows to look for a unit file and not a plain text source file.
Note that commands and functions defined in a INCLUDE file (or a compiled .dsu version of it) may be defined (using #DEFINE) in that file.
The compiler preprocesses included files looking for command and function definitions, in order that they don't produce an "illegal command or function" error when they are compiled.
The VDS compiler functions as a resource compiler. When resources are specified in the filename parameters of DIALOG ADD commands for BITMAP, ICON, TSAKICON and ANIICON dialog elements, a line is added to the resource script that is passed to the VDS linker. This also occurs if a resource is specified in the filename parameter of a LIST LOADFILE command, allowing text files to be embedded as resources. Custom cursors are linked automatically if a resource filename is specified in a DIALOG CURSOR, CUSTOM command. (The second parameter, CUSTOM, is no longer required in this case.)
The compiler will not automatically add resources specified in DIALOG SET commands, DIALOG ADD commands for BITCOMBO or BITLIST dialog elements (where they are specified as part of a text string), or where the resource file names are held in a variable. The #RESOURCE ADD directive can be used to ensure that the required files are linked into the executable file in this case.
The resource linker has the capability to link a Windows XP manifest into the executable file. This file is necessary to tell Windows XP to use the latest version of the common controls DLL which is XP theme-aware. This feature is selectable using the project manager.
The #RESOURCE directive allows you to specify files that are to be linked into the executable file as resources.
When the resource is used in a DIALOG ADD, DIALOG SET or LIST LOADFILE command, the filename must be prefixed by a '#' character.
Note that the resource identifier is normally generated by taking the first eight characters of the filename, not including the directory path or the extension. Windows places an 8-character limit on resource identifiers. Therefore you should ensure that your resource filenames will generate unique identifiers.
An identifier different from the filename may optionally be specified as an additional parameter. This is not generally advisable. When running a script in the IDE, the linked resource does not exist so it is accessed from its original file. Consequently, the filename must be used in the command that accesses the resource, prefixed by a '#' to show that the resource is to be linked when the executable is made. The ability to specify an identifier is supported for internal use and documented for possible future use by extensions.
The resource type MANIFEST is also supported and is used internally to add a Windows XP manifest to the compiled executable file.
Any resource type other than ANIICON, BITMAP, CURSOR, HTML, ICON, STRING or TEXT is treated as a user-defined resource type. The resource will be an exact copy of the file on disk. Image files to be opened using the IMAGE dialog element should be compiled using the user-defined resource type IMAGE.
|Last Updated ( Thursday, 20 December 2007 )|