VBScript in a Nutshell

What VBScript Is Used For: Gluing Together Objects

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:

Ease of navigation

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.

Ease of instantiating objects

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.

Figure 1-1. The Active Server Pages object model

Figure 1-2. A portion of the Microsoft Word object model

Individual objects within an object model expose properties, methods, and events. We’ll discuss each of these in turn.

Properties

Properties 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 named lTimeOut:

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 security reasons.

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 the 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

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:

Response.Write "<HTML><HEAD>"

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.

Events

Methods are routines belonging to an object that we call in code. Event handlers , on the other hand, are functions or subroutines that we write that are called by the VBScript engine in response to some event 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 global.asa file:

Sub Application_OnStart
' application startup code goes here
End Sub

then that code is executed automatically.