VBScript Reference Manual for InduSoft Web Studio

VBScript Reference Manual InduSoft Web Studio
VBScript Hosting Environments
While much of the material contained in the document covers the VBScript language and its use for
IWS applications, it is important to understand conceptually how VBScript works in an IWS environment.
If you browse the web for information on VBScript, you will likely find a plethora of information, but
many of the examples are for running VBScript with ASP using the Windows Scripting Host.
VBScript was developed using a Microsoft technology called ActiveX scripting, which is a COM-based
specification that allows the development of runtime engines for virtually any scripting language. Other
scripting languages include JScript. VBScript can create an instance, or instantiate, a COM object, and
thus through VBScript, many system features can be controlled such as ActiveX Controls, the
FIleSystemObject (providing access to the Windows file system), Microsoft Office Automation (COM),
and ActiveX Database Objects (ADO).
The VBScript Scripting Engine runs on a host, and there are several hosts that can run VBScript (or
any ActiveX Scripting-compliant engines) including Windows Scripting Host and Microsoft Internet
Explorer. VBScript can be used in conjunction with Windows Scripting Host (WSH) to automate system
administration tasks. WSH is part of the Microsoft operating system and treats a VBScript application
like a powerful batch file. VBScript applications can also be found with Web-based shell views. Most
frequently, VBScript is used with Active Server Pages (ASP) for Server-side web applications and
Microsoft Internet Explorer for Client-side web applications.
Stating with Version 6.1, IWS is now a host for the VBScript Scripting Engine. When used in
conjunction with IWS, IWS becomes the only host for the VBScript Scripting Engine that is used. WSH
is not used by IWS, even though WSH may be resident on the PC running the IWS application.
InduSoft has placed implemented VBScript host environment in a manner that is logically consistent
with the current IWS application development environment and licensing method. What this means is
that there are multiple locations in the development environment where VBScript code segments can
be located (so the code is located close to its use), and restrictions placed on the scope of procedures
and variables. In IWS, there is no such thing as a Global Variable that is accessible by any VBScript
code segment. The IWS tags and built-in procedures can be accessed by any VBScript code segment.
The restrictions and interaction with IWS tags and built-in functions implemented by the IWS VBScript
Host are covered in more detail in the VB Configuration and Operation in IWS section.
The VBScript Scripting Engine performs a few key functions. It performs syntax checking in the
development environment (e.g. right mouse click on a VBScript Interface, then select Check Script). It
also interacts with IntelliSense, an auto-completion tool that provides reference to available functions
(VBScript and IWS), IWS tags and ActiveX Controls (name, Properties and Methods). And most
importantly, it executes the VBScript code at runtime, providing error messages if an error occurs. It
should be noted that unlike most programming languages, VBScript is not compiled; it runs in an
interpreted mode. The VBScript Scripting Engine (vbscript.dll) is responsible for interpreting (via the
VBScript Parser, a part of the VBScript Scripting Engine) and executing the VBScript statements, and it
does so quite efficiently. IWS uses Version 5.6 or later of the Microsoft VBScript Scripting Engine.
There are no limitations on the number of VBScript variables supported in IWS, however the amount of
storage for VBScript variables is determined by the amount of memory available in your system.
VBScript variables do not count against IWS tag limits for licensing purposes.
10 InduSoft, Ltd.