This chapter is from the book

Road Map

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
objectsadd-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 datavalues that describe the attributes of the
thing the object represents. Methods are actionsprogram
subroutinesyou 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.

NOTE

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 objectsome 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.2obj1 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 appleobject 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.3File 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.

Object Naming

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.