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 littleit simply binds the rest of the script together. The "things" that the scripting language binds together are components or objectsthat is, the objects exposed by the environment for which the script is being written (like ASP, Internet Explorer, 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 that are particularly noteworthy are 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 which portion of the object model you must navigate to 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 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 retrieve the value of its RootFolder property to get 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 are optional, since the method in this case takes no arguments.
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.