A New Shade of Scripting
Say goodbye to the days of endless cutting and pasting and hello to the wonderful world of Windows Script Components.
- By Chris Brooke
I don't know about you, but I'm excited! The reason for my jubilance
is that, this month, I start my series on Windows Script Components. Topics
like this are what make writing this column so rewarding (and scripting
so much fun). So let's get to it!
The "Old" Way
The ability to cut-and-paste content between different applications is
a wonderful feature of Windows. Heck, I use it all the time to rearrange
my columns, move paragraphs around, and generally organize things in the
hope of turning my tired ramblings into some cohesive prose that you,
dear reader, can decipher.
In other words, cut-and-paste is cool. But it can get old, especially
when you're cutting and pasting the same things time and again.
Take, for instance, your scripts. Over the course of the last several
months, we've created some very interesting scripts together. I've even
talked about how we can encapsulate functionality into classes so that
we can re-use our intellectual property in all of our scripts. Unfortunately,
this involves cutting-and-pasting the classes into each script. Tiresome?
Indeed! Not to mention that it can lead to errors. Thankfully, there's
a solution to the cut-and-paste quandary: Windows Script Components.
The "Gee-Wiz'" Factor
Microsoft has done great things to make administration, systems management,
and, yes, even application development easier. About the only gaping hole
is the lack of a good built-in script editor, complete with syntax checking.
No offense to "Visual" Notepad, but it can get a bit tedious.
Fortunately, Microsoft has made creating Windows Script Components just
as easy with—what else—a wizard! It's called the Windows Script Component
Wizard, and you can download it free from http://msdn.microsoft.com/scripting.
But before I go through the process of creating a Windows Script Component,
let's look at some of the requirements.
Windows Script Components must be in XML format. You can also create
your scripts this way, if you want. I'll actually be talking about that
in future columns (perhaps after I'm done with WSCs).
Every Windows component (WSC or otherwise) must be identified by a Globally
Unique Identifier or GUID. In my mind, this rhymes with squid, but you
may hear it pronounced goo-id. I suppose either way is fine. A GUID is
a 128-bit identification string used by Windows to reference your component.
A registry key is created using the GUID and contains the information
Windows needs to find and use your component.
Because WSCs are in XML format, they can contain methods written in a
variety of languages. You have to specify the language in your <SCRIPT>
tag. It's this way with XML scripts in general, which, as promised, I'll
discuss soon enough.
The good news is that the Windows Script Component Wizard takes care
of most of these requirements, so we don't have to trouble ourselves with
generating GUIDs, putting in most of the XML tags and so on. Let's start
the wizard and check out these cool features.
Figure 1 shows the opening screen. Once you start typing the name, the
Filename and Prog ID are filled in for you. Next, you specify the scripting
language you're going to use in the component, as well as other options
like support for ASP pages and error checking/debugging. I'll talk about
these later; for now, let's continue creating our component.
|Figure 1. Once you start typing the name in the
opening screen of the Windows Script Component Wizard, the Filename
and Prog ID are filled in.
|Figure 2. The Windows Script Component Wizard
allows you define Properties as Read, Write or Read/Write.
Step three of the wizard, shown in Figure 2, allows you to define properties,
which can be Read-only, Write-only or both (just like classes). For this
component, I'm creating two Read/Write properties. If I wish, I can specify
default values for my properties. I've done this for MyProp1, just to
show the difference once the wizard is finished creating the component.
I've done the same thing for the two methods created in Figure 3. MyMethod1
will accept two string values. The reason I don't have to specify whether
these methods will return a value is because I do that in the code within
each method when I write it.
The next step is to define any WSC events. We're not going to do this
yet, so I'm not wasting any space showing you that screen shot. Figure
4 shows the summary page with all the information I entered via the wizard.
You can see that the GUID has already been created (it's that long, freaky-looking
string under the Registration heading). Click Finish, and your first Windows
Script Component will be created. Now all we have to do is put in the
code (which we should already have from our classes, right?).
|Figure 3. Methods are automatically created as
Functions, but you can change them to Subs, if desired. (Click image
to view larger version.)
|Figure 4. As the final step, review the information
and create your component.
Let's look at what the Wizard created. Here's the code listing:
<? xml version="1.0"?>
MyProp1 = "True"
get_MyProp1 = MyProp1
MyProp1 = newValue
get_MyProp2 = MyProp2
MyProp2 = newValue
function MyMethod1(strValue1, strValue2)
MyMethod1 = "Temporary Value"
MyMethod2 = "Temporary Value"
While there are a lot of similarities to plain old classes, there are
also a few differences. First, Property Let has been replaced with Put.
Get is the same, but the syntax is a bit different. You'll also notice
that the wizard took the liberty of putting temporary placeholders into
certain values it knows it'll eventually need. Next month, when we complete
this component by entering code, registering and using it, these differences
will be a bit clearer. For now, treat yourself to a hot fudge sundae.
You've just taken your first step into a larger world!