Mr. Script

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.

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 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.
Define Properties
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.)
Create Your Component
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"?>



   <property name="MyProp1">

   <property name="MyProp2">
   <method name="MyMethod1">
      <PARAMETER name="strValue1"/>
      <PARAMETER name="strValue2"/>
   <method name="MyMethod2">

<script language="VBScript">

dim MyProp1

MyProp1 = "True"
dim MyProp2

function get_MyProp1()
   get_MyProp1 = MyProp1
end function

function put_MyProp1(newValue)
   MyProp1 = newValue
end function

function get_MyProp2()
   get_MyProp2 = MyProp2
end function

function put_MyProp2(newValue)
   MyProp2 = newValue
   end function

function MyMethod1(strValue1, strValue2)
   MyMethod1 = "Temporary Value"
end function

function MyMethod2()
   MyMethod2 = "Temporary Value"
end function



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!

About the Author

Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to [email protected].


comments powered by Disqus

Subscribe on YouTube