Creating a Custom Object with WSC

In my last article I introduced the Windows Script Components technology as a means of creating your own custom COM objects without the need for high level programming or expensive development software. I also showed you how to build a basic object shell using nothing but a text editor and the scripting knowledge you already possess. Today, we’ll take all of that a step further and get our hands dirty creating a real, working object with all of the bells and whistles.

I’m going to assume you read my last article, “Introducing Custom Objects with WSC.”  If you haven’t, you’ll still be able to follow along with this article, but you’ll be missing out on some very important information.  Be sure to take the time to read that article as well.

Let’s jump right in.  The quickest way to create a Windows Script Component is by using Microsoft’s Windows Script Component Wizard.  The wizard is an intuitive tool that will output a basic WSC file for you based on your requirements.  It’s by far the fastest way to begin putting one of these together.  It also generates the unique GUID you’ll need if you plan on registering your object (which you probably do).  Of course, if you don’t plan on doing that, you can simply use the basic file layout that I presented in my last article.

Whether you chose to use the WSC Wizard or not, you’ll need some basic information.  We’re going to be creating a component that will allow us to create and manipulate Compressed Folders.  You can use any name you like or you can use the ones I’ll be providing by copying them from the image below.  The first screen of the wizard should look something like this:


The only real important one here is the Prog ID.  You’ll need to remember this for when you use your component later on.  In my case, I’m using the ZipFolder.WSC Prog ID, so I’ll instantiate my object like this in my scripts:

Set objZipFolder = CreateObject("ZipFolder.WSC")

{mospagebreak title=Using the Script Component Wizard}

Once you provide the basic details about the component name and version, you’ll need to specify the more technical aspects of your component on the second page of the wizard.


Here you should specify the language you intend to use, add any implementations, and provide the type of error checking you would like to use.  Keep in mind that you can change these options later by editing the WSC file, as you’ll soon see.  If you’re not sure what to use, just use the ones in the image above.

Specifying a language is pretty straightforward.  This will add the necessary <script> element to your WSC file.  If you intend to use more than one language, or are undecided, you can always change later, so just pick one.  Today’s example is written in VBScript, so that’s what I’ve chosen.

Implementations are used to control your object’s interaction with its host application.  If you’re using your object in WSH, you do not need any implementations.  The first option adds support for DHTML Behaviors.  This allows your script to interact with the browser DOM when creating components for use in web pages or HTML applications.  The second option provides support for ASP and will allow you to use ASP-provided objects in your script, such as Response.Write() and Server.MapPath().  Adding one or more of these implementations will not affect your component’s use in scripting.  It won’t hurt a thing if they go unused.

{mospagebreak title=Creating the Public Interface}

In steps three, four, and five of the wizard you will be given an opportunity to begin creating your component’s public interface.  These are the properties, methods, and events that your components will expose to the calling script or application, and will be provided by its object.  Keep in mind that you can add, remove, or change these at any time later.  These steps are only meant as timesavers.


In the image above you can see where I’ve added the necessary properties for the ZipFolder component.  All of my properties are Read-Only except for FullName, which is Read/Write.  I haven’t provided any default values either, since I don’t need them.  Now it’s time to add the methods and their parameters.


If your methods have multiple parameters, you can list them all, separated by commas.

{mospagebreak title=Wrapping up the wizard}

In step five of the component wizard you’re given an opportunity to add events to your component.  The ZipFolder component does not have any events, so I simply skipped that step and moved on to the last one, where you’re asked to confirm your actions.  Pressing Finish on this screen will output a WSC file to the directory you specified in the first step.

<?xml version="1.0" ?>

The first line defines the document type as an XML file.  This will cause the XML parser to validate your WSC file before it is loaded by the script host.  You can omit this line if you choose, but I recommend leaving it in place.  Future releases may not be so relaxed about improperly formatted XML files.


   <component id="ZipFolder">

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








The entire WSC file is wrapped inside of an optional <package> element.  If your WSC file contains more than one component, you should leave this element in place.

Next, a <component> element identifies and encapsulates your component.  The name is irrelevant in most cases as it’s only used internally when more than one component is provided.  It’s good practice to provide an id nonetheless.

You should recognize the information in the <registration> section.  Its attributes contain the information you provided in the first step of the wizard, including the description, ProgID, and version number for your component.  All of these items are optional, but you’ll need to provide at minimum a ClassID if you intend to register your component.  It’s a good idea to provide a friendly ProgID as well, otherwise you’ll have to remember that ClassID!


          <property name="FullName">




          <property name="Path">



          <property name="Count">



          <property name="Name">



          <method name="Open">

              <parameter name="strFile"/>


          <method name="Create">

              <parameter name="strFile"/>


          <method name="Add">

              <parameter name="strFile"/>

              <parameter name="blnKeepOriginal"/>


          <method name="AddMultiple">

              <parameter name="varSource"/>

              <parameter name="blnKeepOriginal"/>


          <method name="Extract">

              <parameter name="strFolder"/>



The <public> element defines your object’s public interface.  These are the properties and methods that you want to be available when using your object in other scripts.  Only those properties and methods listed here will be exposed through your object.

       <script language="VBScript">







Finally, the <script> element provides a place for you to put your object’s code.  It’s good practice to specify the language attribute, but the scripting engine is generally smart enough to figure it out if you do not.  You can add as many <script> elements as you like, so you’re not limited to a single language!  You can also mix and match any compatible languages.

I’m out of space once again.  In my next article we’ll finish creating our own custom object.  I’ll show you the code required for the ZipFolder object, teach you some extras features you can use in your own components, and show you how to protect the source code in your components if you choose to distribute them.  Until next time, keep coding!

You can download a working example of this component here.

[gp-comments width="770" linklove="off" ]