The COM Process

Microsoft® Windows® 2000 Scripting Guide

« Previous | Next »   

As a script writer, you have to know only how to create a reference to an Automation object. You do not have to worry about how to locate and load the object because the Windows operating system takes care of that for you. Nevertheless, it is still useful for you to understand what happens between the time when the script runs your CreateObject command and the time when the object itself is available for use.

What is especially useful to understand is that there is no magic here; in fact, the process is relatively simple. When you install an application or a library that contains object classes, that application or library registers itself with the operating system, a procedure that enables the operating system to know:

• That a new COM server is available for use.
• The object classes that the new COM server makes available.

The registration process includes adding a number of subkeys to HKEY_CLASSES_ROOT in the registry. Among the subkeys that are added is one that specifies the Programmatic Identifier (ProgID) for each new object class. The ProgID is a short text string that identifies the name given to each object class. In addition, the ProgID is the parameter used in the CreateObject and GetObject calls to specify the object you want to create. For example, in the following line of code, the ProgID is Excel.Application:

Set TestObject = CreateObject("Excel.Application") 

The ProgID is all the information the operating system needs to locate and instantiate the COM object.

Creating a New Object

When a CreateObject call runs, the script engine parses out the ProgID and passes that to a COM API. This API actually creates the object reference. For example, in this line of code, the string Scripting.FileSystemObject is passed to the COM API:

Set TestObject = CreateObject("Scripting.FileSystemObject") 

The COM API searches the HKEY_CLASSES_ROOT portion of the registry for a subkey with the same name as the ProgID. If such a subkey is found, the API then looks for a subkey named CLSID.

The CLSID subkey maintains a globally unique identifier (GUID) for the Automation object being created. The GUID will look something like this:

{172BDDF8-CEEA-11D1-8B05-00600806D9B6}

The GUID is the way that the operating system tracks and uses COM objects. The ProgID is simply an alias that is easier for script writers to remember.

After the GUID is discovered, the HKEY_LOCAL_MACHINE\Software\Classes\CLSID portion of the registry is searched for a subkey with the same name as the GUID. When the operating system finds this subkey, it examines the contents for additional subkeys that store the information needed to locate the executable file or library file for the object (in the case of the FileSystemObject, C:\Windows\System32\Scrrun.dll). The COM API loads the application or library, creates the object, and then returns an object reference to the calling script.

Server Mode

When an object is created from an executable file, the application is started in a special mode known as Server mode or Embedded mode. This means that although the application is running and fully functional, there is no graphical user interface and nothing is visible on the screen. (You can, however, use Task Manager to verify that the process is running.) Server mode allows you to carry out actions without a user seeing, and possibly interfering with, those actions.

Although server mode is often useful in system administration scripting, sometimes you might want a user interface (for example, if you are displaying data in Internet Explorer). If so, you will need to use the appropriate command for that COM object to make the application appear on screen. For example, the following script creates an instance of Internet Explorer and then uses the Visible command to allow the user to see the application:

Set IE = CreateObject("InternetExplorer.Application") IE.Visible = True 

---

 Send us your feedback

« Previous | Next »