Hey, Scripting Guy! How can I access a type library from within a script?

— XA

Hey, XA. For those of you unfamiliar with the term, a type library is a file or a component that contains type information for a COM object; type information describes the object and the things you can do with it. Among the information found in a type library are the constants used by that object. For example, the FileSystemObject includes these three constants and their values:

ForReading (1)
ForWriting (2)
ForAppending (8)

So what, you say? Well, any time you access a text file using the FileSystemObject, you need to reference one of these constants. For example, suppose you want to open the file C:\Scripts\Test.doc and write the current date and time to that file. To do that, you need a script similar to this:

Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objTextFile = objFSO.OpenTextFile _
    (“c:\scripts\test.txt”, ForWriting)
objTextFile.WriteLine Now
objTextFile.Close

Notice two things here. First, when we open the file (using the OpenTextFile method), we include the constant ForWriting because we have to tell the FileSystemObject whether the file is being opened for reading, for writing, or for appending. Second, notice that — in the very first line of the script — we explicitly assign the value 2 to the constant ForWriting. That’s because VBScript doesn’t have access to type libraries; therefore, we have to tell our script that the value of ForWriting is equal to 2.

By contrast, programming languages like Visual Basic can directly access a type library. If we were writing a Visual Basic program, we wouldn’t have to define the constant ForWriting and assign it the value 2. Instead, we could simply use the constant in our code, and Visual Basic would access the type library and look up the value of ForWriting for us.

In other words, programming languages have access to type libraries; therefore, you don’t have to define any of the constants found in those libraries. VBScript does not have access to type libraries; consequently, you have to manually define any constant used in your script. (And in some cases – such as using ADO to write scripts that interact with databases – you might find yourself using scores of constants, all of which will have to be defined.)

We know: you’re sitting there saying “Come on, come on, give us the workaround, we know you have one.” And you’re right, we do have a workaround; sort of. If you’re writing a “traditional” VBScript script (that is, something with a .vbs file extension), you’re out of luck. But if you’re willing to write a Windows Script File (something with a .wsf file extension), well, that’s a different story.

WSF files made their debut in WSH 5.6 and – to be honest – they haven’t made much of an impact since. (For more information, see the WSF documentation on MSDN). The problem with WSF files is that the advantages they add (like providing access to a type library) are often outweighed by the disadvantages of having to deal with wrapping your script up in a bunch of XML tags. But if XML doesn’t bother you and if you’d really like to be able to access those type libraries, then you can use code similar to this. (Be sure and save this with a .wsf file extension and not a .vbs file extension.)

<package>
    <job id=”Test”>
        <object id=”objFSO” progid=”Scripting.FileSystemObject”/>
         <reference object=”Scripting.FileSystemObject” />
            <script language=”VBScript”>
                Set objTextFile = objFSO.OpenTextFile _
                    (“c:\scripts\test.txt”, ForWriting)
                objTextFile.WriteLine Now
                objTextFile.Close   
            </script>
    </job>
</package>

Of course it’s crazy looking; that’s why very few people use WSF files. If you look inside the <script> tag, however (which is where you place your VBScript code), you’ll see the script we used earlier, with two exceptions: there’s no code for creating the FileSystemObject, and there’s no code defining the constant ForWriting. Instead, we use the <object> tag and the <reference> tag to take care of those two tasks.

In our regular VBScript script, we used this line of code to create an instance of the FileSystemObject:

Set objFSO = CreateObject(“Scripting.FileSystemObject”)

In the WSF file, we use the <object> tag to accomplish this same feat:

<object id=”objFSO” progid=”Scripting.FileSystemObject”/>

Note the ID assigned to the object: objFSO, the same object reference we used in our .vbs file.

After we create our object reference, we can then get access to the type library (and all the constants defined within) by using the <reference> tag:

<reference object=”Scripting.FileSystemObject” />

That’s all there is to it; we can now refer to any constant found in the FileSystemObject without having to define that constant. Cool, huh? Of course, it’s not always this easy; sometimes you might have to use a GUID rather than a ProgId (like “Scripting.FileSystemObject”) when creating an object and a reference. But this will at least get you started.