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!
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.
Last month I asked you to create
a Windows Script Component using the Customer class we wrote back in July.
How’d you do?
<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”/>
If Not objFSO.FileExists(strTextFile)
objTextStream.WriteLine strFName & “ “ &
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:
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:
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
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:
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.