Use a handy utility called XRay.exe to scrutinize objects and understand what they can add to your scripting efforts.

X-Ray Vision

Use a handy utility called XRay.exe to scrutinize objects and understand what they can add to your scripting efforts.

• By Chris Brooke
• 02/01/2000

Last month I made two promises: 1) that this column would continue along the “cool and useful” track laid down by my “Windows Utilities” column last year; and 2) that I would do my best to help you understand the complexities of using objects in your scripts. Well, there must be some sort of cosmic convergence going on, because this month’s column is going to fulfill both promises! Furthermore, this knowledge comes to us via—you guessed it—a Windows utility! (This should help ease the transition for those of you who were distraught over the column change.)

We’ve previously established that components (objects) can add real horsepower to your scripts (see my January column, and my article “Supercharge your Scripts” in the October 1999 issue). However, using components presents its own unique challenges. For starters, perhaps all you know about the components we used in the January column is what I’ve told you. I’ve hinted that there’s more power under the hood just waiting to be released, but how do you find it? XRay.exe, an object model viewer, that’s how!

The Method to My Madness

Before we get into what this XRay.exe does and how it works, perhaps a little background is in order. Quite simply, components are self-contained pieces of compiled code. They have properties (also known as attributes or variables), methods (functions they perform), and events (alerts). You can access these components only via these exposed interfaces. All of the logic inside is hidden from you. As such, these types of components are commonly referred to as “black-box” components. You send something to them, and you get something in return. The rest is voodoo.

Let’s take the FileSystemObject (or FSO), for example. Last month we used the methods OpenTextFile, WriteLine, and Close to write data to a file. However, there are lots of other methods and properties available to us. Moreover, the FSO itself is merely one component of the Windows Scripting Runtime (SCRRUN.DLL), which is the actual file that houses all of these components.

Confused? Let’s look at the Scripting Runtime DLL using XRay.exe and see if we can’t clear some things up.

Try These X-Ray Specs

XRay.exe is included in the Internet Information Server 4.0 Resource Kit Utilities (found in your TechNet subscription). Figure 1 shows the Windows Scripting Runtime loaded into XRay. The title bar shows the filename (SCRRUN.DLL); the top line shows the object name (Scripting). The various components (including the FileSystemObject) are the next branch of the tree, followed by the individual properties, methods, and events. Strictly speaking, the components are called classes. To use a component in our script, we must reference it by objectname.classname, as in:

CreateObject(“Scripting.FileSystemObject”)

The reason we use the object name (Scripting) rather than the file name (SCRRUN.DLL) is because that’s how it’s referenced in the registry (HKEY_CLASSES_ROOT\CLSID\classid). Since the Scripting Runtime is included with Windows, it’s already registered. If we use third-party components (as we will next month), we must first register them using REGSVR32.EXE.

Figure 1. Get a closer look at components with XRay.exe.

The XRay utility shows us virtually everything we need to know about the component. Looking back at Figure 1, you can see that the DeleteFile method is selected. The right pane shows us that in order to use this method, we’re required to pass it a string containing the name of the file to be deleted. Optionally, we can include a Boolean value to force the file to be deleted. Since the method doesn’t return a value to tell us whether or not it succeeded (note the VOID at the beginning), we may want to set this to True.

The Really Fun Part

The method above returns VOID, but not all methods do. Rather, they can return any variable, including a string, integer, or Boolean. Where components get really interesting is when a method from one component instantiates (creates) another component. You may recall that we touched on this briefly last month. Figure 2 shows just such a method.

Figure 2. COMProcreation—components creating other components. What’s the world coming to?

The CreateFolder method is highlighted; in the right pane, you can see that the prototype begins with IFOLDER. This tells us that this method returns (instantiates) another component—in this case a FOLDER component. (I assume that the “I” is there to tell us that this is an “instance” of or “interface” to that component.) The script will look something like this:

Dim objFSO, objFolder
Set objFSO=CreateObject(“Scripting.FileSystemObject”)
Set objFolder=objFSO.CreateFolder(“c:\MyFolder”)

We now have a Folder component that we can look at, set the properties of, and so on. The really, really fun part is that this new component has methods of its own that may create other components. And these components can create still other components. (And you’ll tell two friends, and they’ll tell two friends, and so on…)

By looking at these components using XRay, you can really gain a clear picture of what they can do and how they interact with each other. As we progress on this adventure, I will be using lots of components in my scripts, so start getting used to it now.

Next month, we’re going to take what we’ve learned today and accomplish a fairly tricky bit of scripting: using the Scripting Runtime and two third-party components to perform a file update from an FTP server. Stay tuned—you’re gonna love it! I promise. And you know I always keep my promises.