Understanding Objects

Objects can also represent instances of applications or code that execute outside of the current program or script.  An object reference allows you to interact with this outside program.  The outside program or script must be written with this support.

From a programming standpoint, an object is simply defined as a class reference.  This reference must be imported into your current script.  Regardless of the language you choose to use—whether VBScript, Jscript, or some other—there is a method for connecting to these objects.

Languages that support the use of objects are known as object-oriented languages.  These include languages such as VBScript, Jscript, Perl, and C++ to name a few.  Any of the scriptable languages can be used in WSH so long as you have added support for it.

We’re going to be looking at a specific set of languages known as COM enabled.  Since these objects, or classes, need to be distributed to every computer that runs a script, it was deemed appropriate to preload Windows with a set of the most commonly used objects.  This set of native objects is collectively known as the Common Object Model, or COM.

Most COM objects come in the form of ActiveX controls.

COM has many types of objects intended for many different applications.  Some are more complex than others.  In order to use a COM object in WSH, it must have a scripting interface.  This means that it must have been designed to allow scripts to access it.  We’ll discuss this in more detail later in this article.

For now, understand that objects allow you to execute code that is outside of your current script.

Objects typically offer three types of data or code to a script.  They may use any or all of these three types.  They include:

• Methods – These are code procedures that perform specific tasks.  They are generally in the form of subroutines and functions.
• Properties – These are in a sense variables.  They represent a stored value.  This value may be retrieved or set dependent upon whether or not the property is read-only.
• Events – These are special hook and sink strategies that are used to notify other code when a specific event has taken place.  Code can be written to react to these events.

These data types must be exposed explicitly by the class in order to be used publicly.  Let’s take a look at the Shell Automation Service object as an example.  This is a COM object that allows you to interact with the Windows shell.  Before you can use it, it must be referenced, or instantiated, in your code.  VBScript and Jscript each do this differently.

VBScript:

Set objShell = CreateObject("Shell.Application")

Jscript:

var ShellObject = new ActiveXObject("Shell.Application");

VBScript’s CreateObject function and Jscript’s ActiveXObject function both return an object reference that must be assigned a variable name.  You indicate which object you would like to instantiate by specifying its namespace.  This is a unique identifier that follows the COM naming convention.

Objects may also contain sub-objects.

Once an object has been instantiated, you can use its reference to access any exposed properties and methods.  In OOP, or object-oriented programming, this is done with dot syntax.  The remaining examples in this article will be written in VBScript.

Set objShell = CreateObject("Shell.Application")

objShell.MinimizeAll

In the example above we’re calling the MinimizeAll method of the Shell object to minimize all open windows.  Notice that dot syntax is being used: object.method.

Set objFso = CreateObject("Scripting.FileSystemObject")

Set colDrives = objFso.Drives

intNum = colDrives.Count

In this example, we’re using the FileSystemObject’s Drives property to return a collection of drives.  This is a sub-object of the FileSystemObject.  We then use its Count property to return the number of sub-objects that it contains.

In VBScript and WSH, some objects do not require instantiation.  They are made available by the environment.  Two examples are the WScript object, which references the currently active WSH session, and VBScript’s Err object, which references the Standard Error output stream.

Because these objects are made available by the environment, they can be accessed immediately without first connecting to them or assigning them to variables.  You can see both in use in the following example.

WScript.Echo WScript.FullName

If Err.number <> 0 Then

   WScript.Echo "There was an error."

End If

Notice that there was no need to include any Set statements.  Instead, we are able to begin using properties and methods from these objects immediately.

Now that you understand how to use objects, let’s take a closer look at how COM objects are built.  They require a few pieces in order to function properly.

The primary piece is the code base.  This is the class itself.  Most often these are compiled as either DLL or OCX files depending upon their type.  This is the code that defines all of the procedures associated with the class.  These are identified using a GUID, or Globally Unique Identifier.

They must also have an interface definition file.  This is a sort of manifest file that indicates what the class does and what procedures it exposes.  It also identifies the interfaces that can be used to access them. Most often these IDL files are compiled into another type of file known as a Type Library.

Finally, the pieces have to be put into place.  In other words, they need to be present on the current system and the operating system needs to know where to find them when needed.  This is done through a process known as registering.  When a COM object is registered, entries are made in the system registry that define its namespace and the location to the executable files.  Some objects can even have their type libraries built at the time they are registered.

A GUID is a long string of hexadecimal characters.  While they are human readable, remembering them would be nearly impossible.  Due to their length, it’s impractical to even reference them by their GUID outside of registration.

Writing and constructing COM objects is far beyond the scope of this article.  I’ve given you a very brief look, but don’t consider this to be totally inclusive.  For our purposes, you need to understand that COM objects require installation on the system on which they are being used and that they are identified by a GUID.  Most often they will also have a friendlier namespace associated with them as well.

COM objects come in many styles depending upon their intended use.  They allow you to control nearly every aspect of the computing experience from controlling operating system behavior to automating individual programs.  These objects can add a lot of power to your script or program without you needing to write the code for yourself.

In the case of scripting, they can provide functionality that you simply couldn’t write due to the limitations of the language and the environment.

Some types of COM objects include OLE, OLE Automation, ActiveX, COM+ and DCOM. Each of these is built on a different technology to provide a different type of functionality.

If you would like to explore the different COM objects available on your system, you should download a COM object viewer.  Many programming environments such as Visual Studio provide one for you.  Other third party solutions are also available.

Most of the time, these will let you view the publicly available methods and properties that are exposed by these objects.  The documentation will typically be archaic, but a little trial and error can prove useful.  Just understand that many of the objects you find will not be scriptable, so most of them will not work in WSH.

You can find a plethora of information concerning COM objects with a good Google search or by stopping by Microsoft’s MSDN site.

Any time that you are forced to reuse several related methods or properties, you may wish to consider creating a COM object—especially if you intend to distribute them for use in other scripts or programs.

Even if you don’t know or have the ability to program in any compiled languages, there is a way to create your own custom COM objects in WSH.  We’ll tackle that topic in a future article.  Until then, keep coding!