Using a .wsf file. Microsoft added .wsf files to WSH 5.6. In these files, you can use the <reference> element. This element automatically connects to the specified type library and loads the constants' values for you. For example, to have your script automatically access the constants defined in the Scripting Runtime Library, you simply insert the following code inside the job containing the scripts that need the constants:
<reference object =
"Scripting.FileSystemObject"/>
Although the <reference> element is easy to use, this solution has a few limitations. First, if you add this element but don't have the referenced object installed on the system, the script will error out before execution even starts. Another limitation is that you don't get a chance to see the values associated with the constant names. Thus, you don't get a chance to learn or document them.
A Better Solution
Because constants' values are in a type library, you can use the TypeLib Information Objects (aka TlbInf32) library to get the information. The nickname TlbInf32 comes from the original name of the file containing this component: tlbinf32.dll. TlbInf32 is itself a component, which means you can easily call it from script. You can then use it against files or even objects currently being used in a script.
Office 2000 and VB 6.0 include TlbInf32. (TlbInf32 isn't shipped as a part of Windows and, to my knowledge, has never been distributed separately by Microsoft.) Visual Studio .NET 2002 and later uses the file as well, but Microsoft renamed it to vstlbinf.dll.
In most cases, you don't need to install TlbInf32 everywhere, just on one machine that has the components you need to inspect. Although you can browse for tlbinf32.dll or vstlbinf.dll, the simplest way to check for TlbInf32's existence is to try to call it with the code
Dim tla
Set tla = CreateObject( _
"Tli.TliApplication")
If this code works, TlbInf32 is correctly installed and functioning. If not, make sure TlbInf32 is present on your system-and register it when you find it. If you have more than one copy of TlbInf32, make sure you register the most recent version.
Lots of object browsers use TlbInf32. Some browsers are specifically designed for scripters. Object browsers typically work by opening a type library and looking at the interfaces it describes. Simplifying a bit, interfaces act as doorways to the objects you can create in scripts, so when you look at a particular interface, you can see the methods and properties of any objects you would create from it.
This process is the reverse of how a script works. Scripts usually start by creating a reference to a particular object rather than a particular interface. Although it's more work, you can still use TlbInf32 in a script. Listing 1 demonstrates how with the FSO object. In this code, the tla variable contains a TLIApplication object. Because TLIApplication can access other objects currently being used in a script, it can provide you with the interface through which it was called, as callout A in Listing 1 shows.
As I mentioned earlier, type libraries contain interfaces. Because the FSO object was created directly through an interface in the type library and because an interface always knows its parent, you can get the parent of the interface, which is the type library, or TypeLibInfo object. In Listing 1, the tlb variable contains a TypeLibInfo object. This object has a Constants property, but the name is poorly chosen. The Constants property refers to a collection of enumerations of constants because constants exist in groups within the type library. For example, ForAppending, ForReading, and ForWriting are all members of an enumeration that's a single element of Constants.
An ill-chosen name isn't all you have to worry about with Constants. This property has a lot of redundancy. For example, the Constants property contains enumerations of hidden constants, which are constants that typically just mirror the exposed constants. So, you need to filter out the hidden constants. Fortunately, the hidden constants all exist in enumerations whose names begin with an underscore (_), so you can search on that character to find and remove them.
After you filter out the hidden constants, you'll have the true constants, which are referred to as members of an enumeration. Each member is itself an object, with its own properties. Two useful properties are the Name and Value properties. By calling these properties, you can obtain the constants' values. Although the Constants property is complex, the code to filter out the hidden constants and show only the Name and Value properties' contents is compact, as callout B in Listing 1 shows.
The code in Listing 1 returns a lot of information—more than 30 constants in seven different enumerations. That output includes the values for the desired constants:
ForReading = 1
ForWriting = 2
ForAppending = 8
After you generate the constants' values, you can save them in a file and use them in your scripts.
TlbInf32 definitely makes documentation easier. When I ran the code in Listing 1 against Microsoft Word, 2771 constants from 270 enumerations were passed to me in seconds. I certainly don't need all that information, but if I'm going to write a script that accesses Word and need a constant's value, I can quickly look it up.
Prev. page
1
[2]
3
next page 
