|
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
NOTE
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.
Engine
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.
Script
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
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.
URL
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
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).
- 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.
- 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.
- 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.
- 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.
- 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.
- Script Invocation—Finally, the events,
properties and methods of the script itself are invoked through a standard OLE binding
mechanism .
Hint
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.
UnInitialized
In this state, the engine is little more than an
idea. No program has called it and no program is using it.
Initialized
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.
Started
In this state, the connections have still not been
made, but code that was loaded during initialization can be run automatically.
Connected
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.
Disconnected
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.
Closed
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 .
Summary
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&A
- 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.
Workshop
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).
Quiz
- What is the purpose of client-side scripting?
- What ActiveX script engines are included with the SDK
and Microsoft Internet Explorer?
- Why are scripting languages usually scaled down
versions of another language or hobbled in some way?
- What two different things are described by the word host?
- What three components are required in a scripting
situation?
- What groups of objects are available to VBScript?
- What attribute of the script element must always be
defined?
- How do you keep a browser that does not support
script from inadvertently viewing coded script as content?
- Where should script that modifies the content of a
document be placed?
- What is the fee for licensing VBScript or JScript in
your own applications?
|
