- Introduction to Objects
- Using Objects with VBScript
- Using Objects with JScript
- Using Objects with ActivePerl
- Using Objects with ActivePython
- Using the WScript Object
- Locating and Using Unusual Objects
This chapter is from the book
This chapter is from the book
This chapter is from the book
Locating and Using Unusual Objects
Several powerful, commonly used objects provided with Windows are documented by Microsoft in the Windows Scripting reference documents, and I discuss most of these in Chapters 4–9. If you're new to scripting, these should be enough to get you started, so you might want to skip ahead to Chapter 4.
In addition to these standard objects, many developers and companies provide add-in objects for free or for sale. There is, however, a wealth of objects already on your computer; hundreds of COM objects are supplied with Windows, and hundreds more are added if you install applications such as Word, Excel, and Visio. Many are designed just for the use of specific application programs and are of no use to script authors. Others are general-purpose objects for use by scripts and compiled programs. How can you tell which objects are installed on your computer and of those, which are useful for scripting? To be honest, identifying useful objects is tricky business, but if you enjoy detective work, read on.
To get an idea of what I mean by "hundreds of objects," take a look at the Windows Registry.
To view the Registry on Windows 7 or Vista, click Start, type regedit into the search box, and press Enter. On XP, click Start, Run; type regedit ; and press Enter. Expand the entry for HKEY_CLASSES_ROOT and scroll down past the . xxx -format entries to those that spell out names like "something dot something," as shown in Figure 3.4. Most of the entries from here down represent object classes; you can tell which ones do by the presence of a CLSID or CurrVer key under the object name.
)
Figure 3.4 COM object classes are listed in the Registry under HKEY_CLASSES_ROOT, after the .xxx entries. Objects have an associated CLSID entry.
In Figure 3.4, the FaxControl.FaxControl.1 entry has a CLSID entry, so it is an object. A CLSID (or class ID) is a long, essentially random number that object authors use to give their object a unique "fingerprint." A CurrVer entry, such as the one found under FaxControl.FaxControl, is used when there's a chance more than one version of the class program might be installed on your computer. The CurrVer value tells Windows where to look to find the class information for the most recent version of the object. Find that entry, and you find the object's CLSID.
The first step in scouting out new and interesting objects is to peruse the Registry for names that sound interesting. For this example, I'll follow up on the FaxControl.FaxControl.1 object from Figure 3.4.
When you've found a CLSID value for a potentially interesting object, locate the matching value under My Computer\HKEY_CLASSES_ROOT\Clsid, where you find the information Windows uses to locate and run the program file that actually manages the object.
Figure 3.5 shows the class information for FaxControl.FaxControl.1. The InprocServer32 entry shows the actual program module (usually a DLL or OCX file) that manages the object. In this case, the program is \WINDOWS\system32\Setup\fxsocm.dll. The name of this object and the location of its DLL make it sound like it might be used for setting up the Fax service. But how?
)
Figure 3.5 Class ID information for the FaxControl.FaxControl.1 object.
The first thing you have to check is whether the object is even suitable for use in script programs; some aren't. The first test, then, is to see whether you can create an object in your chosen scripting language. Use the server.object name you found under HKEY_CLASSES_ROOT. In VBScript, it looks like this:
set obj = CreateObject("FaxControl.FaxControl.1")
WScript.echo "CreateObject worked!"
If this script produces an error message, the object can't be used in scripts. If it runs without an error message, as it did when I tested FaxControl.FaxControl.1, the object has passed the first hurdle.
Your next step should be to search the Internet for references to the object name (for example, search for FaxControl.FaxControl.1 or FaxControl.FaxControl). I've found that Google is a great place to start. If you see references to pages on msdn.microsoft.com, these might point to complete documentation for the object in question. Be sure to search Google's "Groups" section, too. Many programmers haunt the comp.xxx groups, and if you're lucky, you might find an archived discussion about the object. (Unfortunately, if you do a Google search for FaxControl.FaxControl, you will most likely find only references to this very discussion from this book or from its first edition titled Windows XP Under the Hood, but no documentation.)
If you can't find documentation online, Microsoft or the object's creator might have supplied a help file describing the object. See whether the Clsid Registry values list a help file ending in .hlp or .chm. If it does, at a command prompt type
start pathname\helpfile.xxx
where pathname\helpfile.xxx is the full path to the help file listed in the Registry. This might show you how the object works. In the case of FaxControl.FaxControl.1, there is no help file.
If no help file is named, don't give up. Because COM objects are designed to be used by many programming languages, they can—if their developer wanted them to—provide a list of methods, properties, and their arguments to any program that asks. If your mystery object has this feature, you might be able to burrow into the object's program file to find its usage information.
The easiest way to do this is with an object browser, a program that's designed to do just this sort of burrowing. Microsoft provides one with many of its applications. If you have Microsoft Word, Excel, or PowerPoint, the Object Browser is included as part of the Macro Editor. Start the application and click Tools, Macro, Visual Basic Editor. Then, click View, Object Browser. If you have the full developer's version of Visual Basic installed, run it and click View, Object Browser.
To view information for a questionable class, you need to tell Word (or Visual Basic, and so on) to look into the class's program file. To do this, click Tools, References. Click Browse and locate the DLL or OCX file you found in the Registry. Click Open, and the library appears as a checked item in the Available References list, as shown in Figure 3.6.
)
Figure 3.6 Selecting an object class type library to view in the Object Browser.
When the object type is listed and checked under Available References, click OK.
Then, select the class name from the library list in the upper-left corner of the Object Browser window, as shown in Figure 3.7. Choose object types in the left panel; the browser displays the object's methods, procedures, and predefined constants in the right panel under Members. You can select the objects in this list one by one, and in the bottom panel, the browser displays the method or procedure's arguments, if any, and any explanatory text it can dig up.
)
Figure 3.7 Viewing a class's type information in the Object Browser.
If you don't have any of the applications I've mentioned, another tool, called the OLE/COM Object Viewer, is provided with the Windows XP and Windows 2000 Resource Kits which you can download from www.microsoft.com. You can also download this tool directly from www.microsoft.com by searching for "OLE/COM Object Viewer."
The OLE/COM Object Viewer is much more difficult to use than the Object Browser. Here are some tips for using this viewer:
- Try to find the object of interest under Object Classes, All Objects. I've found that not all the objects I'm interested in are listed there. For example, Scripting.Dictionary is present, whereas Scripting.FileSystemObject is missing. If you can't find it there, look under Type Libraries.
- Double-click the library or object to view its class information. This information is designed for COM object programmers, not end users, so it's going to be tough to understand.
- Typedef items list some predefined constant values used by all the objects provided by the server.
- Coclass items define the objects the class server can create. If you view the contents of a coclass item, you find the class's predefined constants, properties, and methods.
Although either object browser can show you what sorts of values the methods and properties expect and return, it can't tell you what these values mean, so you have to experiment to find out if and how you can use them. In the case of FaxControl.FaxControl.1, the Object Browser showed two properties and two methods, as listed in Reference List 3.3.
Reference List 3.3. Properties and Methods of the FaxControl.FaxControl Object
Properties
IsFaxServiceInstalled
Returns a Boolean value.
IsLocalFaxPrinterInstalled
Returns Boolean value.
Methods
InstallFaxService
Returns no value and takes no arguments.
InstallLocalFaxPrinter
Returns no value and takes no arguments.
This sounds pretty straightforward. There are no arguments to supply to these methods, so there's no detective work required there. Also, the names sound pretty self-explanatory. This object lets you know whether the Fax service and the Fax Printer are installed, and it can install them. But does it work?
Here's a sample script I wrote to check:
set obj = CreateObject("FaxControl.FaxControl.1")
WScript.echo "IsFaxServiceInstalled =", obj.IsFaxServiceInstalled
WScript.echo "IsLocalFaxPrinterInstalled =", obj.IsLocalFaxPrinterInstalled
The results when I ran it on a Windows XP computer that had a modem but did not have the fax service set up were
IsFaxServiceInstalled = 0 IsLocalFaxPrinterInstalled = 0
When I ran the script
set obj = CreateObject("FaxControl.FaxControl.1")
obj.InstallFaxService
Windows Setup asked for my Windows XP CD disk and installed the Fax service and printer. The first script's output became this:
IsFaxServiceInstalled = -1 IsLocalFaxPrinterInstalled = -1
Here, -1 means True (any nonzero value means True), so the object does the job you expect it to. Here's a script that can automatically be sure a user's Windows XP system has the Fax service as well as a fax and printer installed:
set obj = CreateObject("FaxControl.FaxControl.1")
if not obj.IsFaxServiceInstalled then
WScript.echo "Installing Fax Service..."
obj.InstallFaxServic
elseif not obj.IsLocalFaxPrinterInstalled then
WScript.echo "Reinstalling Fax Printer..."
obj.InstallLocalFaxPrinter
else
WScript.echo "Fax printer is ready to go."
end if
This is a good example of the functionality you can find by digging into the many objects that come with Windows, and it shows the kinds of scripts you can write to manage Windows computers so other users don't have to poke around with the Control Panel themselves.
(On Windows Vista, this script works only on the Business, Enterprise and Ultimate editions. The Home editions don't come with built-in faxing support, but, all versions of Windows 7 include the Faxing service.)