If you create very large scripts, or frequently reuse the same subroutines in several different scripts, you may want to split your script code into more than one file. Each script file is called a module.
A script can call subroutines and functions defined in other modules. In addition to procedures, global variables, type definitions, and enumeration definitions may be shared among modules. Just as procedures make long scripts easier to manage and debug, modules make large script projects easier to manage.
The File | New Module command in Scripter adds new code sheets to the workspace. Each sheet is stored in a separate file. When routines in one code sheet are used by other sheets, the code sheets are called modules. Scripter supports three types of modules:
· Code modules are used for stand-alone scripts and for storing libraries of useful procedures that can be called from other modules. The scripts described in this chapter are code modules, which contain a Main subroutine. Code modules without a Main subroutine cannot be run, but the routines contained in them can be shared by other scripts. Code modules are stored in files with a .BAS extension.
· Class modules are used to define objects that you can use in other modules. A class module defines the properties and methods that the object supports. Other modules access the object's properties and methods using the same syntax that is used to access Voxler automation objects. Unlike Voxler objects, new instances of the object defined in a class module are created using the NEW keyword. Class modules are stored in files with a . CLS extension.
· Object modules are identical to class modules, except that when a script uses the object defined in an object module, one instance of the object is automatically created. Additional instances of an object defined in an object module can be created with the NEW keyword. Object modules are stored in files with an . OBM extension.
See Also
Private and Public Definitions