We’ve outlined the four major areas in which VBScript is used, but if we were to look at how scripts are written in each of these environments, we’d quickly note far more differences than similarities. (Because of this, we’ve devoted a separate chapter to each area in which VBScript is commonly used.) Yet this is misleading. If we take a more high-level view, we can see that the role of VBScript and the role of the environment in which its scripts are run are broadly similar, regardless of the environment’s unique features.
Typically, scripting languages are described as “glue” languages. That is, they are used to glue things together. That means that the glue itself does relatively little—it simply binds the rest of the script together. The “things” that the scripting language binds together are components or objects—that is, the objects exposed by the environment for which the script is being written (like ASP, MSIE, Outlook, or WSH), as well as objects that are exposed by external applications, environments, or components (such as ActiveX Data Objects, Collaboration Data Objects, Microsoft Word, Microsoft Excel, or custom components created in Visual Basic). A map of a single high-level object (such as the Microsoft Word application, for instance, which is represented by the Application object) along with its child objects is known as an object model .
One type of object model that’s particularly suitable for scripting is shown in Figure 1.1. In this particular case, the figure shows the ASP object model. Two features are particularly noteworthy: its flatness and its lack of interdependence. (Contrast it, for example, with the Microsoft Word object model, a portion of which is shown in Figure 1.2.) In particular, a flatter object model and/or one whose objects have a fair degree of independence has a number of advantages:
Since the object model is flat, you don’t have to be concerned with navigating upward and downward through the object hierarchy. This makes coding easier, reduces the time spent debugging, and improves performance.
Since objects are independent of one another, you can easily create them or retrieve a reference to them, instead of having to figure out to which portion of the object model you must navigate in order to instantiate that object or which property or method you must call that returns that object.
Individual objects within an object model expose properties, methods, and events. We’ll discuss each of these in turn.
are attributes or values of an object that can be read and set. (In
other words, properties are variables that belong to an object.) As
long as the value returned by the property is not an object, setting
and retrieving property values requires a simple assignment
statement. For example, the following line of code stores the value
of the ASP Session object’s TimeOut property to a variable
lTimeOut = Session.TimeOut ' Retrieve property value
Storing a new value to the property is just as easy. For instance, the following line of code changes the value of the Session object’s TimeOut property to 10 minutes:
Session.TimeOut = 10 ' Set property value
Some properties are read-only; that is, while you can retrieve a property’s value, attempting to set it is not permitted and generates an error. For example, the code:
lSVars = Request.ServerVariables.Count ' Read-only property
assigns the count of the number of variables in the Request
object’s ServerVariables collection to a variable named
lSVars. Attempting to set the value of the
Count property, however, generates an error, since the property (as
well as the ServerVariables collection itself) is read-only. Rarely,
you may also encounter properties that are write-only, or that are
write-only under certain conditions; you can set the property’s
value, but you can’t retrieve it. Typically, this is done for
Many properties return either individual objects or collections. (A
collection is an object that serves as a container for other data
items or objects.) These also require assignment statements that use
Set statement. For example, you can retrieve a
reference to the root folder of the
C: drive on
a local system with a code fragment like the following:
Set oFS = CreateObject("Scripting.FileSystemObject") Set oFolder = oFS.Drives.Item("C").RootFolder
Note that in the second line of code, we navigate the File System object model from its top-level object, the FileSystemObject object, to the Drives collection object. We use the collection’s Item property to retrieve a reference to the Drive object representing Drive C:, and then we retrieve the value of its RootFolder property to retrieve a reference to an object representing the drive’s root folder.
Methods are simply public functions or subroutines exposed by an object. You call them in the same way that you call any function or subroutine, except that you must preface the method name with a reference to the object whose method you are calling. If you are calling a subroutine or a function whose return value does not interest you, you can use syntax like:
which calls the ASP Response object’s Write method to write the
beginning of a web page to the server’s output buffer in
response to a client request. To call a method that returns an
object, use an assignment statement along with the
Set statement, and enclose the argument list in
parentheses. For example:
Set oShell = WScript.CreateObject("WScript.Shell") Set oShortcut = oShell.CreateShortcut("My First Script.lnk")
is a fragment from a WSH script that creates a shortcut and returns
the WshShortcut object representing that shortcut. If the method
returns an ordinary value, the
Set statement must
not be used. For instance, the second line of the code:
Set oFS = CreateObject("Scripting.FileSystemObject") strTempFile = oFS.GetTempName( )
calls the FileSystemObject object’s GetTempName method to
retrieve a temporary filename, which is stored to the variable
strTempFile. The opening and closing
parentheses after the method name here are optional, since the method
in this case takes no arguments.
Methods are routines belonging to an object that we call in code.
, on the other hand, are functions or
subroutines that we write that are called by the VBScript engine in
response to some
that occurs to the object. For instance, when an ASP application is
accessed for the first time, its OnStart event is fired. If we have
included code like the following in our
Sub Application_OnStart ' application startup code goes here End Sub