Windows Scripting and Objects
- Oct 4, 2002
This chapter introduces the concepts of objects, methods, and properties. It provides the background you'll need for the following seven chapters.
Read this chapter to see how to use the objects provided with Windows Script Host with different scripting languages.
To get the most out of this chapter, you should be familiar with at least one script programming language.
The last section of the chapter shows how you can learn about the many undocumented objects provided with Windows.
Introduction to Objects
All the Windows Scripting languages that I discussed in Chapter 1, "Introduction to Windows Script Host," provide the basic tools to control a script's execution and to manipulate strings, numbers, dates, and so on, but they don't necessarily provide a way of interacting with Windows, files, or application software. These functions are provided by objectsadd-on components that extend a language's intrinsic capabilities. In this section, I'll discuss what objects are and will introduce the terms you'll run into as you work with them. In the following sections, I'll discuss how objects are actually used in several different programming languages.
In the most general sense, objects are little program packages that manipulate and communicate information. They're a software representation of something tangible, such as a file, a folder, a network connection, an e-mail message, or an Excel document. Objects have properties and methods. Properties are data values that describe the attributes of the thing the object represents. Methods are actionsprogram subroutinesyou can use to alter or manipulate whatever the object represents.
For example, a file on your hard disk has a size, a creation date, and a name. So, these are some of the properties you would expect a File object to have. You can rename, delete, read, and write a file, so a File object should provide methods to perform these tasks. An important aspect of objects is that they are self-contained and separate from the program that uses them. How the object stores and manipulates its data internally is its own business. The object's author chooses what data and procedures to make accessible to the outside world. In programming jargon, we say that an object exposes properties and methods; these items compose its interface. Figure 3.1 shows the interface of a hypothetical File object.
Figure 3.1 This hypothetical File object has an interface that can be used by other programs. How the File object actually stores its information and does its job are hidden.
Objects need a mechanism through which they can exchange property and method information with a program or a script. Because each programming language has a unique way of storing and transferring data, objects and programs must use some agreed-upon, common way of exchanging data. Microsoft uses what it calls the Common Object Model (COM). COM objects can be used by any compatible language, including VBScript, JScript, C, C++, C#, Visual Basic, Perl, Object REXX, and so on. COM objects may also be called ActiveX Objects, Automation Objects or OLE objects, but regardless what they're called, the technology is based on COM.
There are object models other than COM, which operating systems other than Windows use, but in this book I'll discuss only COM.
In the next several chapters, we'll see objects that represent files, folders, network connections, user accounts, printers, Registry entries, Windows applications, e-mail messages, and many more aspects of your computer and network. Windows XP comes with software to provide you with a wealth of different objects. You can also download, buy, or create additional objects of your own devising.
Classes and Instances
Two other terms you're likely to run into while working with objects are class and instance. The distinction is the same as that between a blueprint for a house and the house itself.
The word class refers to the object's definition: Its interface (the properties and methods it provides) and its implementation (the hidden programming inside that does the actual work). Many object classes are provided with Windows, and you can add or create more, as discussed in Chapter 9, "Creating Your Own Scriptable Objects."
When you actually use an object in a program, the class program creates an instance of the object; this is a parcel of computer memory set aside to hold the object's data. The class program then gives your program a reference to use when manipulating the objectsome identifying value that the class program can use to determine which particular instance of the object your script or program is using. Figure 3.2 illustrates this point: Variables obj1 and obj2 are variables that reference instances of a File object.
Figure 3.2 obj1 and obj2 refer to objects of the File class. This illustration shows two instances of the File object.
A reference is treated like any other variable in your program. Just as you can use functions such as sqrt() and left() to manipulate numeric and string values, you can use the object's methods and properties to manipulate an object reference.
Containers and Collections
As mentioned earlier, an object represents some real-world, tangible thing, such as a document or a hard drive, and it has properties that represent the tangible thing's attributes. For example, an apple object might have attributes such as color and tartness. The actual data stored for the color might be a character string such as "red" or "green". Tartness might be represented as number from 0 (sugary sweet) to 10 (brings tears to your eyes).
An object describing a file on a hard drive might have properties such as filename (a character string) and size (a number). An object representing a hard drive might have properties describing the hard drive's size, volume name, and also the drive's contents.
Now, the contents of a hard drive could be represented as a list of filenames or an array of string values. However, it might be more useful if the hard drive could yield a list of file objects that you could then use to work with the files themselves. This is actually how many objects work. When appropriate, objects can return references to other objects. When an object needs to give you several other objects, it will give you a special object called a collection, which holds within it an arbitrary number of other objects. For example, a Folder object might represent a folder on your hard drive, and its Files property might yield a collection of File objects, which represent the files in the folder, as illustrated in Figure 3.3.
Figure 3.3 File and Folder objects can represent the contents of a hard drive. The contents of a folder can be represented by collections of File and Folder objects.
A collection object can actually hold any type of object inside it, and the collection object itself has properties and methods that let you extract and work with these objects. This is a common thing to see in object programming: "container" objects that contain other objects, of any arbitrary type. You'll see many examples of collections in later chapters.
Windows ActiveX objects use container objects that have two properties: Item and Length. The Length property indicates how many items are in the collection. The Item property retrieves one of the individual items. For some collections, you can extract individual objects from the Item collection using Item(0), Item(1), and so on, but for many collections, the Item property requires a name or other arcane bit of identifying information. Therefore, each scripting language provides a more general way of letting you examine all the objects in a collection. I'll discuss this in more detail later in the chapter.
Collections are pervasive in Windows script programming, and some languages have special means of working with them. I'll give examples of using collections in each of the scripting languages discussed later in the chapter.
Because objects are separate program components, scripts and other programs that use them need a way to locate them and tell Windows to activate them. In this section, I'll describe how this is done.
Each programmer who creates an object class gives it a name that, with any luck, is fairly self-explanatory. For example, Scripting.FileSystemObject is designed to be used by Windows Script Host (WSH) programs to view and manage hard drives, files, and folders. Each of the programming languages you can use with WSH has a way of creating an object instance given just this name. For example, in VBScript, the statement
set fsobj = CreateObject("Scripting.FileSystemObject")
does the job, whereas in Object REXX, the comparable statement is
fsobj = .OLEObject~New("Scripting.FileSystemObject")
In either case, the statement causes the Windows Script Host interpreter to ask Windows to create an instance of the specified object. Windows looks up the object name in the Registry, finds the name of the program file that manages this object class (usually a file whose name ends in .dll or .ocx), and fires up the add-on program. The class program creates an instance of the object and gives your script a reference with which it can use and manipulate the object.
I'll show you how to do this in each WSH-compatible language later in this chapter. For almost all cases, this is all you need.
In the remainder of this chapter, I'll tell you how to use objects in VBScript and other languages. The next section on VBScript will follow the tutorial style of Chapter 2, "VBScript Tutorial," whereas the descriptions for other languages will assume more experience with programming.
Finally, at the end of the chapter, I'll tell you how to find useful objects not discussed in the later chapters of this book.