Web based School

ActiveX Scripting

Previous Next

Chapter Three

ActiveX Scripting

You have learned that ActiveX programming involves the manipulation of documents and other objects over the Internet. You also know that the Internet consists of a diverse population of client and server machines.

With all these different types of control objects available to the programmer, a language must be used to manipulate those objects. This language should have the added functionality of being able to work well over a distributed environment like the Internet. In this section, you will learn about:

  • HTML scripting

  • JScript

  • VBScript

  • The ActiveX Scripting Engine

This section discusses ActiveX scripting technology, but does not contain an in-depth discussion of ActiveX syntax and programming-specific syntax. Instead, the discussion focuses on what happens behind the scenes with ActiveX scripting. Later, you will learn more details about two forms of ActiveX scripting—VBScript and JavaScript.

Client-Side Scripting.

Lights, camera, ACTION! No, that's not what scripting is about, but there are some similarities. Client-side scripting is a way to define procedures that manipulate the properties, methods and events of an object. The script itself is executed on the user's local machine rather than on some remote server.

Running a server-side script once for each connection that requests it can be very taxing on the system resources of a busy server (such as WWW.Netscape.Com or WWW.Microsoft.Com). Memory and storage can become gobbled up, and processing speed deteriorates as more and more redundant code is loaded, run, and unloaded (see Figure 3.1).

Figure 3.1. Too many simultaneous connections from multiple clients to the same server can result in access refusal for the latecomers.

This resource drain can be relieved somewhat by the use of HTML client-side scripting. Client-side scripting shifts the code processing burden from the server (which would have to run zillions of instances at once and transmit the queries and responses back and forth over the Net) to the client (which would only have to run one instance at a time—locally). For a graphical representation of this kind of bottleneck, see Figures 3.1 and 3.2.

Figure 3.2. Most scripting functions are best performed by the client, rather than the server, to avoid bottlenecks.

In the preceding figure, the server must run a script five times in one minute, unless the five hosts can simultaneously run one script each in one minute.

When you are browsing the Web, you are using one host to access information on any number of other hosts. Scripting can occur on either side of that connection. For example, the server to which you are connecting could run an ISAPI, CGI, Perl or other script, and your browser could run a bit of VBScript, JScript or other ActiveX script.

As powerful as most programming languages are at full strength, they can provide strangers on the Net more access to your system than you want them to have.

A scripting language is usually a subset of another language. For example, VBScript is a subset of Visual Basic. JScript is a subset of Visual J++ (code named Jakarta). By restricting some processes that are normally available, such as features of file I/O, programmers can use a hobbled version of a programming language.

This gives you some degree of protection against malicious or undesirable programs. Features such as shelling to the operating system and formatting the hard drive are simply not available through a good scripting engine .

Scripts, Hosts and the Engines

Another difference between scripting and programming is the way the finished program code is compiled and executed. A normal program is usually compiled into an executable to be run by itself, or it can be compiled into a library of features, such as a DLL (dynamic link library). A script, on the other hand, requires two things besides itself to run—a host and an engine.

Connection Confusion
The concepts host, client, server, and so on, as they apply to the Internet, can get awfully confusing.
In the most basic connections, a client requests something and a server processes this request.
Often confused with a server, a host is one of several systems connected to the Internet. The host might or might not be a server to other machines that then might or might not have their own connections to the Internet. Regardless of how it's connected, every system attached to the Internet is a host.
On most other networks, such as LANs, a host is a dedicated server. On the Internet, however, a host can be any machine connected to the Internet with a dedicated or dynamic IP (Internet Protocol) address. That's just about everybody.

Script Hosts

In reference to scripting, a host is a program (such as Microsoft Internet Explorer or Netscape Navigator) that uses a script engine to run a script on the local machine. The host application is the intermediary program between the user and the server, and resides on the user's machine. Any OLE program can act as a script host when it implements either the IActiveScriptSite interface or the optional IActiveScriptSiteWindow interface.


In order for a host to run a bit of script, it must reference a scripting engine. This engine is usually a library or set of libraries (such as VBScript.DLL or JScript.DLL) that tells the host how to interpret the script. ActiveX scripting is Microsoft's implementation of the HTML script element. Every ActiveX scripting engine must implement either IActiveScript, or the optional IActiveScriptParse interface.

The script engine (that is, a runtime file or files installed on the local machine) has a two-pronged approach to facilitating Internet programming.

First, script engines use all the objects in the standard Internet Explorer Object Model for Scripting. This includes the document object, the anchor object, the history object, and so on.

Second, script engines also support a few objects that are built into the engine itself. This extends the power of basic HTML scripts. If these JScript, VBScript and MSIE objects are not enough, you can add other objects to your document, as you will learn in the final chapters of this guide.


The script itself is the code, in whatever syntax is supported by the script engine. The script can make reference to the various objects supported within the context of the document. These include the document object and other embedded objects (the final chapters of this guide, which cover ActiveX controls, present these objects and object models in greater detail). For an graphical representation of how client scripting works across a net, refer to Figure 3.3.

Figure 3.3. The relationships between the parts and pieces of ActiveX scripting.

A script can be loaded into the system by one of two interfaces. The whole script can be loaded using IPersist*, or a portion of the script can be attached to an object using IActiveScriptParse .

HTML Scripting

Although it's not necessary to be a fully qualified OLE programmer to use most forms of script, it certainly helps. Programming and scripting are very similar. In fact, early versions of Basic (such as those found on the Radio Shack TRS-80 and the Commodore 64/128) were not as powerful as most of today's elemental scripting languages!

Programmers do their thing within one or several programming languages. These languages define the way you control processes on your computer, and are usually very powerful. On newer machines that have APM (advanced power management), a programmer can write a program that actually turns off the computer for the night.

Script writers, on the other hand, are dealing with a somewhat less powerful environment. This limited environment disallows most hardware control features without actually disabling them. For example, a script writer can make the user's computer play sound files in MIDI and Wave format, but the script writer cannot install the drivers that play those files. The drivers would have to already be installed on the client machine.

The Script Element

The insertion of client-side script into an HTML document requires the <SCRIPT> container tags to define pieces of text within that document that are code segments. The script element has three attributes (two of which are optional). These include the SRC, Type and Language elements. A <SCRIPT> tag looks something like this:
<SCRIPT Type="text/vbscript" Language="VBScript" src="VBScript.vbs"> </SCRIPT>

Because some browsers do not support the <SCRIPT> tag, this tag is sometimes ignored. This becomes problematic when content is displayed because the content and the script become mixed together.

Older browsers (such as Mosaic and Lynx) usually do support the <COMMENT> tag, so make your pages friendly to non-ActiveX browsers by by adding <COMMENT></COMMENT> tags around your code. These tags are ignored by the script if the browser can run them, and filters out the text of the script if the browser cannot run them. This format for coding script looks like this:
<SCRIPT Language="VBScript"> <!-- 'My Code -- > </SCRIPT>

The Language Attribute

The primary attribute of the script element is the Language attribute . The Language attribute is the only attribute that must always be specified. Normally this will be VBScript or JavaScript because these are the two primary scripting engines used by the two primary Web browsers.

The SRC Attribute

The optional SRC attribute tells the browser that the code for this entry can be found in an external file. In the preceding example, the code is in a file called, VBScript.vbs in the current directory.

The Type Attribute

If you refer to an external source file in a script tag, you might need to use the Type attribute to define the MIME type for the script file. For instance, in the preceding example, the code is in a text file with a .VBS extension. The user's browser will retrieve the script the same way it retrieves text/vbscript MIME type files.

JScript and VBScript

When using script within an HTML file, the best place to put your code might be at the top of the file (within the head element). Code can be placed in a later portion of the document, but it must be before the </HTML> tag. One reason to place code at the top of a file is if the code actually writes to the file.

Often, people speak of ActiveX scripting. There is no "ActiveX Script" language per se. ActiveX script is the name given to the use of OLE interfaces in a scripting engines. Jscript and VBScript are the usual two that are referred to, because Microsoft includes their engines with MSIE (see Figure 3.4). ActiveX script engines for Perl, LISP and others are also being developed.

If, for instance, you were to use VBScript's Document.Write method, the text that is written would need to be figured in before the rest of the page is displayed. This ensures that the browser knows what to put where on the page when the page is viewed.

Figure 3.4. ActiveX script shares objects, properties, methods and events with VBScript and JScript.

Another reason to place code at the beginning of a file is for procedures that, logically, would only be launched after the page is viewed. This could include a procedure that would be launched when the user clicks a button or an image map. Since the code is vital to the operation of the page, it needs to be loaded before the rest of the page.

One school of thought says to put every bit of code in the head element to ensure that the script is available before the user needs it. Another school of thought says to put some code at the end of the page so the text will display more quickly.

Additionally, you can place code in the middle of a document, preferably near an object with which the code interacts. If you code your script this way, most browsers will load and display the content of the document as it is downloaded. When it gets to the object and the script, it will pause (or hiccup) as it displays the content. During this pause, the object and code are grabbed from the Net and are appropriately displayed.

Placing the code at the beginning of the document produces a pause at the beginning of the document. Depending on the size of the code, the pause could last as long as a minute before the user is able to view the first line on the page. In cyberspace, this seems like a lifetime and causes the user to choose another page.

As a rule, it's a good idea to place as much of your script at the top of a page, or in an external file, if possible.

Licensing the Engines
Some programs are so customizable that you need to make a whole programming language available within the application. Good examples of programs that use scripting are Telix, Qmodem and ProComm.
These dial-up terminal programs are very similar to Windows 95's HyperTerminal. To allow program users to customize the features of interactions with dial-up servers, the developers of these packages included scripting languages specifically for their package.
Telix uses a scripting language called SALT (Script Application Language for Telix) SALT allows users to create custom logon/logoff processes for their dial-up connections, then takes them several steps further. Users can customize the way the program responds to different prompts from the dial-up connection. They can then automate long and complex data entry and retrieval tasks that would otherwise require a human to sit at the keyboard and make intelligent decisions.
If you create an application that is very complex and powerful but requires simple decision making, you can include a scripting engine in your application. VBScript and JScript are licensed to everybody, provided they acknowledge Microsoft in the About box of the application. No money is required.


JScript is Microsoft's implementation of JavaScript. System support for JScript is installed by default with Microsoft Internet Explorer. Additionally, Microsoft maintains an excellent resource for up-to-date information related to JScript development at http://www.microsoft.com/jscript.

Microsoft's Web sites for the most up-to-date documentation and information on their two scripting engines are located at

The ActiveX Control Pad is a handy utility for writing JScript code. Even more powerful than JScript is Visual J++ (also known as Jakarta), which allows users to compile Java applets, OLE-level code and other high-power Internet tools.

Installing the ActiveX Control Pad and the ActiveX Layout Control
This would be a good time to install the ActiveX Control Pad and its co-control, the ActiveX Layout Control . The installation routine for these can be found on the enclosed CD-ROM. Installing them is very simple (as is using it!). To install these utilities, follow these steps:
Step 1—Locate and double-click SetupPad.exe.
Step 2—Allow the setup program to install the program into its default path.
Then, for the ActiveX Layout Control, follow these same steps using SetupALX.exe.
The URLs ftp://ftp.microsoft.com/developr/MSDN/CPAD and ftp://ftp.microsoft.com/msdownload/ieinstall take you to the FTP sites for the ActiveX Control Pad and its associated ActiveX Layout control. As ActiveX travels through its inevitable evolutions, you will want to check these sites frequently for the most up-to-date versions. You will learn more about this handy little editor in the next chapter.

As with Java, JScript is (or soon will be) available for a variety of platforms, including Mac, PC, and UNIX, and extending to Sun, HP and even IBM platforms.


VBScript is another big Microsoft implementation of HTML script. In many respects, VBScript is similar to JScript, with an additional twist.

VBScript is a subset of VBA (Visual Basic for Applications), which is a subset of VB (Visual Basic ), and can easily port applications back and forth among the three. Going the other way, VB is a superset of VBA, and VBA is a superset of VBScript. For a less confusing, graphical representation of this relationship, refer to Figure 3.5.

Figure 3.5. Visual Basic has become a hierarchical family of programming tools.

Some of the features within VBA that are not found in VBScript include DDE (Dynamic Data Exchange) link features and declarations for calls to external DLLs. VBScript also has significantly fewer debug and error handling routines. For the person creating the script, these are handy. By eliminating these features, however, the user does not need to install large runtime files on his local machines—just small runtime files.

You will learn more about VBScript later in this guide .

The ActiveX Scripting Engine

ActiveX supports the use of customized script engines (that is, engines other than VBScript and JScript). ActiveX script engines can be created for LISP, Scheme, SALT, Perl or even your own custom or proprietary language.

Developing your own programming language is a very complex process (don't even try it unless you know what you are doing!). Creating a script engine for a pre-existing language is only slightly less difficult.

This chapter does not go into all the details of creating your own engine. To do so requires a much larger volume. But for those of you who need your own script engine, or are developing one for the open market, there are a few features of ActiveX Scripting with which you should be familiar.

If you just plan on using engines created by others, such as VBScript and JScript, you will want to be familiar with how the engine works. You will also want to know how it crashes.

Host and Engine Interaction

There are several steps involved in making a connection between a host (such as Microsoft Internet Explorer) and an engine (such as VBScript).

  1. Project Creation—In this step, the document is loaded onto the local machine. The document is usually an HTML document, but can be just about anything that has your script in it.

  2. Engine Creation—In this step, the host calls the CoCreateInstance() function and specifies the CLSID of the script engine. This creates an instance of the script engine, and is required before you can get the script to run.

  3. Script Loading—In this step, the script itself is retrieved. If it is being retrieved from persistent data, the script is sent directly to the script engine. If the script must be retrieved from a remote site, a null script object is created. At this point, the remote script is retrieved and fed into the new script object. Only then can it be fed to the script engine itself.

  4. Script Item Loading—In this step, the pieces of the script, such as forms and the engine's namespace, are loaded into the script object. This is sometimes referred to as populating the script properties.

  5. Running the Script—During the initialization of a scripting process, the host and the script are first connected. A few changes occur, including static bindings and hooking up to events.

    • Static Bindings—After the script is initialized, it uses the GetItemInfo() method to retrieve information from any necessary objects.

    • Hooking up to Events—After static bindings are made, Connection Points are made to any relevant objects.

  6. Script Invocation—Finally, the events, properties and methods of the script itself are invoked through a standard OLE binding mechanism .

Although you can place your script in a file separate from the hypertext document, you might want to place as much as possible within the document itself to speed things up.
One reason for this increase in speed is fairly obvious. When the scripts are kept in separate files, HTTP (the networking protocol) must go through the whole process of connecting with, sending requests to, and receiving responses from the server. This happens for each document and image that is in the HTML document.
A less obvious reason is connected to the local (client-side) operation of the scripting engine. When creating the script object, fewer IPersist* interfaces need to be coded. Also a simplified process of creating the script object is used within the HTML document itself.

The Engine as an OLE/COM Object

If you are an OLE or COM programmer, you can create your own scripting engine using a program such as C++.

Required Interfaces

To qualify as an ActiveX script engine , your project must support the IActiveScript interface. This gives the OLE programmer access to the basic scripting features of the engine.

The control must also support at least one of the following IPersist* interfaces :

  • IPersistStorage—If this interface is supported, the information required to run the control can be placed in a file at a remote URL and can be retrieved through the data attribute of the object element.

  • IPersistStreamInit—If this interface is supported, the data attribute can use the Internet MIME encoding features for transferring various types of multimedia and other data over the Internet. This feature of the data attribute follows a format somewhat similar to Data=base64-encoded byte stream and is followed by the ASCII Base64 encoded stream of data for the script.

  • IPersistPropertyBag—If this interface is supported, it enables an HTML author to use the param attribute of the object element to any several of the control's properties.

Engines and the Registry

ActiveX engines are added to the system registry in two component categories: CATID_ActiveScript and CATID_ActiveScriptParse.

If the engine's CLSID is entered in CATID ActiveScript, it must support IActiveScript and one of the IPersist* interfaces mentioned earlier. However, if the engine's CLSID is entered in CATID ActiveScriptParse, it must support IActiveScript and IActiveScriptParse interfaces.

Engine States

An ActiveX script engine can exist in any of several states. The programmer who creates the engine might find it necessary to monitor these states, and to enable or disable functions of the engine as these states change. This case logic can ensure that users are not able to attempt impossible tasks, such as trying to disconnect from a server that was never successfully initialized.


In this state, the engine is little more than an idea. No program has called it and no program is using it.


In this state, the script has been initialized (that is, called) but has not yet started connecting to the referenced objects and event handlers that it will need to run.


In this state, the connections have still not been made, but code that was loaded during initialization can be run automatically.


In this state, the engine is going full-tilt boogie. All the connections to objects and events have been made, code is ready to execute, states are being monitored and events are firing.


In this state, the script is still loaded into the engine, but it has been disconnected from all objects and events with which it might have been communicating. The script is not automatically reset, however, because that would send everything back into the initialized state. This would cause your script to run endlessly.


In this state, the script is over with, whether it completed normally or not. If it was communicating with other objects in the system, it should tell them when it closes. If external objects try to reference it after it closes, it will just return a bunch of errors .

Figure 3.6. The features of an ActiveX script engine .


You should now have a strong familiarity with the features of ActiveX scripting. It allows the use of a variety of general and specialized scripting languages. Client-side scripting relieves an Internet server of much of the burden of processing multiptle simultaneous requests.

You also know about the two major script engines supported by ActiveX, JScript and VBScript. JScript is Microsoft's implementation of Sun Microsystem's JavaScript, which was the first wide implementation of HTML scripting. VBScript, which is part of the Visual Basic family of programming languages, is very similar to JScript, but is aimed more toward today's front-end developers who use Visual Basic and Visual Basic for Applications.

You are also aware of the basic interaction between a script host, engine, and code. (A full definition of the script engine interface would include several of the OLE features represented in Figure 3.6) A host is a program that manages scripting functions by coordinating the retrieval of a script and the processing of that script by an engine. A script is a bit of code written in a scripting language, which can be run by a script host, such as Telix, Internet Explorer or Netscape. An engine is the files and routines required to interpret, compile and run a script.

Prospective OLE programmers have been introduced to some of the features of a script engine, such as the processes it uses and the OLE interfaces it implements.


  • Q Why does ActiveX script use two scripting engines instead of choosing one standard and sticking with it.

  • A There is no "ActiveX Script" per se. ActiveX scripting is a technology, not a program. The two engines supplied with the SDK and Microsoft Internet Explorer are simply two types of script engines that can be used on the Net.
    The value of implementing VBScript and JScript right off the bat is that each, to some degree, is already widely used in the programming world. JScript is based on JavaScript, which is the first wide implementation of HTML scripting. VBScript is based on the very popular Visual Basic, and is a gateway product for bringing current programmers into the Internet programming fold.

  • Q What IDEs can be used to program VBScript?

  • A The ActiveX ControlPad is probably the best utility for quick editing of VBScript within an HTML Document. Visual Basic for Applications v5.0 will support VBScript and provide online help, which the ControlPad currently does not.

  • Q What IDEs can be used to program JScript?

  • A Again, the ActiveX Control Pad is probably the best utility for quick editing of JScript within an HTML Document. Visual J++ will support JScript and provide online help, which the ActiveX Control Pad currently does not. It will also allow you to compile applets and integrate with other Visual programming applications.

  • Q What is the deal with IPersist* interfaces?

  • A When an object, such as a script, is created on a local machine, it has properties that need to be populated, or defined. This information is retrieved by way of an interface with a name that begins with IPersist (such as IPersistStorage or IPersistStreamInit). It can be retrieved from a remote host or from the local machine; either way, the IPersist* Interface is the pipeline to that data.

  • Q What is the difference between an IActiveScript interface and an IActiveScriptParse interface?

  • A An IActiveScript Interface defines a method for retrieving the script. An IActiveScriptParse interface defines a method for retrieving any portion of a script, which is useful when bits of script are placed throughout various parts of an HTML document instead of all within the head element.

  • Q What programming languages and IDEs can be used to create an ActiveX scripting language?

  • A Any programming language that can create an ActiveX control should be able to create a script engine. This includes Visual Basic 5, Visual C++, and even Delphi.


List some of the programming features you use in Visual Basic that you would not want available in a scripting engine (for security's sake), then list some of the programming features you use in Visual Basic that you would consider indispensable in a scripting engine (for security's sake).


  1. What is the purpose of client-side scripting?

  2. What ActiveX script engines are included with the SDK and Microsoft Internet Explorer?

  3. Why are scripting languages usually scaled down versions of another language or hobbled in some way?

  4. What two different things are described by the word host?

  5. What three components are required in a scripting situation?

  6. What groups of objects are available to VBScript?

  7. What attribute of the script element must always be defined?

  8. How do you keep a browser that does not support script from inadvertently viewing coded script as content?

  9. Where should script that modifies the content of a document be placed?

  10. What is the fee for licensing VBScript or JScript in your own applications?

Previous Next