Mr. Script

Behold the Power!

Object-oriented programming with Windows Script Components can keep you from having to reinvent the wheel—and there are some cool bells and whistles, to boot!

• By Chris Brooke
• 11/01/2001

In high school I did my senior term paper on the history of computers (yes, I was a geek even way back then!). Fifty-five years ago the first computer, ENIAC, was powered up. It consisted of roughly 73 bazillion vacuum tubes, was bigger than my house, and was an engineering marvel (with an equally “marvelous” price). Today, my $600 PocketPC can blow it away. I can’t even imagine what technology will be like when my baby boy is my age and working as a professional computer geek (you never doubted it for a minute, did you?). He’ll certainly consider me a dinosaur. “Writing scripts? Using a mouse? How barbaric!”

Well, I’ve got one thing going for me—I put my script code into reusable classes and components so I don’t have to “reinvent the wheel” on a daily basis. Object-oriented programming is a concept that’s here to stay. Let’s use it to complete our homework assignment.

Homework
Last month I asked you to create a Windows Script Component using the Customer class we wrote back in July. How’d you do?

<?xml version="1.0"?>
<component>

<registration
  description="Customer Object"
  progid="CustomerObject.WSC"
  version="1.06"
  lassid="{0a3340cc-4f65-425a=b8a8-9ac5156ea288}"
>
</registration>

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

<public>
 <property name=”FName” internalname=”strFName”/>
 <property name=”LName” internalname=”strLName”/>
 <property name=”EMail” internalname=”strEMail”/>
 <property name=”Company” internalname=”strCompany”/>
 <property name=”TextFile” internalname=”strTextFile”/>

 <method name=”AddCustomer”/>
</public>

<script language=”VBScript”>
<![CDATA[

Sub AddCustomer()
 If Not objFSO.FileExists(strTextFile) Then
 objFSO.CreateTextFile(strTextFile)
 End If
 Set objFile=objFSO.GetFile(strTextFile)
 Set objTextStream=objFile.OpenAsTextStream(8)
 ‘For appending

 objTextStream.WriteLine strFName & “ “ & strLName
 objTextStream.WriteLine strEMail
 objTextStream.WriteLine strCompany
   objTextStream.WriteLine
   objTextStream.Close
End Sub

]]>
</script>

</component>

I Object!
You’ll notice that I added a new element to my XML:<object>. Because the Customer Class uses the FileSystemObject, I can declare this as an object in the component and avoid using CreateObject. The FileSystemObject is instantiated at the same time as the WSC. Because the objFile and objTextStream objects can only be created by the FileSystemObject, I can’t use <object> to declare them.

The next step was to import the code from the class. Because the class used standard Read/Write properties, I removed the procedural properties created by the Script Component Wizard. I then copied the code from the AddCustomer method in the class to the AddCustomer method in the component, removing the CreateObject line for objFSO and adding an extra objTextStream.WriteLine method to make the resulting text file more readable. This process was very easy, as most of the work was done by the wizard.

WSC Ya Later
Remember when we first ran through the Windows Script Component Wizard? Remember all those settings that I said I’d get to later? Well, it’s later! You may create hundreds of Script Components without ever using these features, and that would be just fine. However, if you ever intend to use these WSCs anywhere but in the Windows Script Host, you might find these features useful.

Support Active Server Pages: This allows your WSCs to include the functionality of ASP pages. It gives your component access to the intrinsic objects of ASP such as Server, Response, Request, Session and Application. For instance, your component could use Response.Write to send output to the ASP page.

When you select this option in the wizard, it adds this entry:

<implements tyupe="ASP" id="ASP"/>

You now have full access to these ASP objects.

Use this scriptlet with DHTML behaviors: This allows you to implement the DHTML behaviors of Internet Explorer. The component is instantiated on the client (by IE) rather than on the server (by IIS) and gives you access to some cool features. For example, you can bind to the “onmouseover” event of IE and specify custom behavior such as changing the highlighting color, text spacing and so on. Setting it up is a bit more complex than setting up ASP support:

<implements tyupe="Behavior">
     <attach event="onmouseover" handler="do_onmouseover"/>
     <attach event="onmouseout" handler="do_onmouseout"/>
</implements>

You then can create methods to respond to these events. You can also create custom events (this is another option in the wizard). There’s much more to implementing DHTML behaviors that I just don’t have room for here. Perhaps one day I’ll revisit this topic and really get into it.

Error Checking and Debugging: These options simply turn on error checking and debugging. If you select both checkboxes in the wizard, the resulting WSC file includes this line:

<?component error="true" debug="true"?>

Error checking allows the script component parser to display details about errors in your script. Without it, an error in your component simply returns a generic error. With debugging enabled, you can use the script debugger to debug your components. Both of these settings are useful when you are initially creating your WSC components.

The “Hidden” Error Checker
When the wizard creates your script component, it automatically puts a tag at the top called <?xml version=”x.x”?>. This specifies that the following XML should be strictly interpreted. It’s required should you ever want to use an XML editor to edit the file. However, it’s not required for the script component parser. If you leave it out, the XML can be interpreted loosely (like HTML). Element names are no longer case-sensitive, for example. If you do this, though, you open up another issue.

CDATA: I’m sure many of you were wondering why the wizard started the <script> section with <![CDATA[. This goes back to the rules of XML parsing. The VBScript or JScript code would confuse the XML parser. Let’s assume one of your methods compares two variables …

If Var1 < Var2

The parser might think the “is less than” operator is actually the beginning of an XML tag. Needless to say, this could really mess things up. CDATA makes the entire section opaque to the XML parser. Unfortunately, there’s another side to this coin. If you elect not to enforce script XML validation by eliminating the <?xml ?> tag, you also need to eliminate the <![CDATA[...]]> tags. Otherwise, your component will report errors at registration, instantiation and runtime.

That about wraps it up for Windows Script Components. Next month I’ll move on to a related topic: .WSF script files.