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:
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.
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 .
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.
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 book.
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 book, 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 .
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 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 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 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.
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.
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.
URL
Microsoft's Web sites for the most up-to-date documentation and information on their two scripting engines are located at
http://www.microsoft.com/jscript
http://www.microsoft.com/vbscript
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 book .
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.
There are several steps involved in making a connection between a host (such as Microsoft Internet Explorer) and an engine (such as VBScript).
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.
If you are an OLE or COM programmer, you can create your own scripting engine using a program such as C++.
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 :
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.
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.
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).
Note
Refer to the Appendix, "Answers to Quiz Questions," for the answers to these questions.
