by Bill Schongar and Paul Lagasse
Let your VBScript code be the best it can be. No, you don't send it into the armed forces; instead, you send it to VBScript boot camp. Teach your code some discipline, make it work as part of a team, and turn out code that you can depend on to do the job you set it to, and do it right the first time. You're already starting out with good material; you just have to make it as suitable as possible for your needs.
Optimizing VBScript isn't a daunting task; it's just a combination of a dash of common sense, along with a hefty dose of what's best in your situation. Unlike its bigger cousins, Visual Basic and Visual Basic for Applications, VBScript doesn't have a lot of room for gray areas about what will make it faster, slower, or better. The subset of functionality limits the extent that you can "tweak" code, but it does present a couple of new things to consider.
This chapter takes a look at what kinds of things you can do to make your VBScript application run a little better and speed up your development cycle. This includes
If you're already a Visual Basic guru, much of the stuff you'll see here will be pretty familiar, and you might even have your own special tricks you want to add in your own development. If you've never touched Visual Basic before, don't worry. Everything in this chapter is first and foremost aimed right at you, to give you the edge you need to make great, clean code.
There's a lot to be said for being able to read your own writing, and the same holds true for code. HTML pages in and of themselves can often be a mess, and when you add source code for a program, it gets to be a little bit chaotic. That can either work for or against you, depending on what you have in mind.
One of the wonders of embedded scripting is that what you write is out there for everyone to see. All your functions, all your tricks, and all your work and source code are just one download away from just about everyone's view. Like a business interview, what you present in that first impression may give people an impression (accurate or not) of the quality of your code. If it sprawls all over the HTML source, they'll just be glad it works. If, on the other hand, the code is cleanly spaced out and thoroughly commented, it shows a sense of organization.
Keeping code orderly is an easy task as long as you start at the beginning. Record why you used particular functions, so that if you have to fix a problem or change the code later you'll be ready to make the changes without trying to decipher possibly cryptic entries. Don't go overboard, though! Remember that anything you type has to get downloaded by the end user, and they don't appreciate several hundred lines of comments taking up download time on every page.
If you'd like to make folks work a little harder to see your source code or are just more organized by nature, there are options available to you. The most complex would be to roll all your VBScript code into an ActiveX control, and make people download it if they want to use your code. Since that kind of defeats the purpose of using VBScript in the first place and brings a whole new level of programming complexity into the mix, you'll probably want to avoid that route.
A much more efficient and convenient method is to take advantage of Microsoft's HTML Layout files (.ALX files). These are files that combine all the ActiveX control tags and assorted details so that they don't show up on the main page. This gives you two benefits: First and foremost, it gives you a separate file in which to organize the VBScript portion of your HTML file. If you're using repetitive code (on forms validation as an example), you may not want the same information cut and pasted into every HTML file. If you update the ALX file once, any HTML page that references it will automatically get the update.
To show what kind of difference this makes in readability, Listing 11.1 shows a small HTML page with VBScript embedded in it, while Listings 11.2 and 11.3 show the same HTML page with a Layout control object and its associated ALX files. The more complex the script, the better off you are removing it from the HTML page. Once you start using ActiveX controls, it's almost impossible to do much without going this route.
Listing 11.1. HTML and VBScript in one page.
<HTML>
<HEAD>
<TITLE>New Page</TITLE>
</HEAD>
<BODY>
<SCRIPT LANGUAGE="VBScript">
<!--
Dim Index
Dim Caption(5)
Caption(1) = "See the Caption has changed"
Caption(2) = "Of Course you could do a lot more"
Caption(3) = "With this type of control structure"
Caption(4) = "Like Moving the text across the screen"
Caption(5) = "And allow the user to set the speed"
Sub IeTimer1_Timer()
Index = Index + 1
If Index = 6 then Index = 1
IeLabel1.Caption = Caption(Index)
end sub
-->
</SCRIPT>
<OBJECT ID="IeTimer1" WIDTH=39 HEIGHT=39
CLASSID="CLSID:59CCB4A0-727D-11CF-AC36-00AA00A47DD2">
<PARAM NAME="_ExtentX" VALUE="1005">
<PARAM NAME="_ExtentY" VALUE="1005">
<PARAM NAME="Interval" VALUE="2000">
</OBJECT>
<OBJECT ID="IeLabel1" WIDTH=368 HEIGHT=27
CLASSID="CLSID:99B42120-6EC7-11CF-A6C7-00AA00A47DD2">
<PARAM NAME="_ExtentX" VALUE="9737">
<PARAM NAME="_ExtentY" VALUE="714">
<PARAM NAME="Caption" VALUE="This text will change at regular intervals">
<PARAM NAME="Angle" VALUE="0">
<PARAM NAME="Alignment" VALUE="4">
<PARAM NAME="Mode" VALUE="1">
<PARAM NAME="FillStyle" VALUE="0">
<PARAM NAME="FillStyle" VALUE="1">
<PARAM NAME="ForeColor" VALUE="#E8FD00">
<PARAM NAME="BackColor" VALUE="#000000">
<PARAM NAME="FontName" VALUE="Arial">
<PARAM NAME="FontSize" VALUE="12">
<PARAM NAME="FontItalic" VALUE="0">
<PARAM NAME="FontBold" VALUE="0">
<PARAM NAME="FontUnderline" VALUE="0">
<PARAM NAME="FontStrikeout" VALUE="0">
<PARAM NAME="TopPoints" VALUE="0">
<PARAM NAME="BotPoints" VALUE="0">
</OBJECT>
</BODY>
</HTML>
Listing 11.2. HTML page with the Layout control.
<HTML> <HEAD> <TITLE>New Page</TITLE> </HEAD> <BODY> <OBJECT CLASSID="CLSID:812AE312-8B8E-11CF-93C8-00AA00C08FDF" ID="sample2_ALX" STYLE="LEFT:0;TOP:0"> <PARAM NAME="ALXPATH" REF VALUE="file:J:\temp\sample2.ALX"> </OBJECT> </BODY> </HTML>
Listing 11.3. ALX file containing VBScript.
<SCRIPT LANGUAGE="VBScript">
<!--
dim Index
dim Caption(5)
Sub IeTimer1_Timer()
Index = Index + 1
If Index = 6 Then Index = 1
IeLabel1.Caption = Caption(Index)
end sub
-->
</SCRIPT>
<SCRIPT LANGUAGE="VBScript">
<!--
Sub Layout1_OnLoad()
Caption(1) = "See the Caption has changed"
Caption(2) = "Of Course you could do a lot more"
Caption(3) = "With this type of control structure"
Caption(4) = "Like Moving the text across the screen"
Caption(5) = "And allow the user to set the speed"
end sub
-->
</SCRIPT>
<DIV ID="Layout1" STYLE="LAYOUT:FIXED;WIDTH:389pt;HEIGHT:26pt;">
<OBJECT ID="IeLabel1"
CLASSID="CLSID:99B42120-6EC7-11CF-A6C7-00AA00A47DD2"
STYLE="TOP:0pt;LEFT:41pt;WIDTH:281pt;HEIGHT:17pt;ZINDEX:0;">
<PARAM NAME="_ExtentX" VALUE="9922">
<PARAM NAME="_ExtentY" VALUE="609">
<PARAM NAME="Caption" VALUE="This text will change at regular intervals">
<PARAM NAME="Angle" VALUE="0">
<PARAM NAME="Alignment" VALUE="4">
<PARAM NAME="Mode" VALUE="0">
<PARAM NAME="FillStyle" VALUE="0">
<PARAM NAME="FillStyle" VALUE="0">
<PARAM NAME="ForeColor" VALUE="#E8FD00">
<PARAM NAME="BackColor" VALUE="#000000">
<PARAM NAME="FontName" VALUE="Arial">
<PARAM NAME="FontSize" VALUE="12">
<PARAM NAME="FontItalic" VALUE="0">
<PARAM NAME="FontBold" VALUE="0">
<PARAM NAME="FontUnderline" VALUE="0">
<PARAM NAME="FontStrikeout" VALUE="0">
<PARAM NAME="TopPoints" VALUE="0">
<PARAM NAME="BotPoints" VALUE="0">
</OBJECT>
<OBJECT ID="IeTimer1"
CLASSID="CLSID:59CCB4A0-727D-11CF-AC36-00AA00A47DD2"
STYLE="TOP:0pt;LEFT:8pt;WIDTH:25pt;HEIGHT:25pt;ZINDEX:1;">
<PARAM NAME="_ExtentX" VALUE="873">
<PARAM NAME="_ExtentY" VALUE="873">
<PARAM NAME="Interval" VALUE="2000">
</OBJECT>
</DIV>
Something to keep in mind, though, is that anytime you add a control to the page, you increase download time if the user doesn't have it on his system. When you add an ALX file, you also add the delay while that file is retrieved. If absolute performance is your goal, and you don't use any HTML Layout controls to add functionality to your script, you would be better off avoiding the use of ALX files to store your code. However, since the chances of the HTML Layout control being on a user's system are very high if they've ever visited another site, it's your call.
One of the most effective pieces of optimization is to take a piece of code that doesn't run, and then fix it. Sound obvious? You'd be surprised how many people and how many pages put together functions or code, and then don't check the whole thing, or don't check it after that one last "quick change." After all, it worked when it was tested the first time; what's going to stop it from working with that insignificant modification? Yep, you guessed it... practically anything.
The simplest test case for any VBScript application is to load it into whatever is supposed to run it, and see if any errors pop up. The great thing about Microsoft's VBScript runtime is that for safety's sake it's going to perform some checks on script validity before it does anything with the information it contains. So, in about the time it takes you to double-click the HTML file, you can find out if something's wrong. Most of the time this kind of spot-check is only going to spot very basic syntax errors, like missing a comment tag, or spelling a variable differently in a few places, but it's also the kind of stuff that a pair of tired eyes passes over far too easily.
There are a wide variety of error-checking and debugging steps you can take, which you can find explained in detail in Chapters 12, "Debugging," and 14, "Customize Your Web Page with Cookies." Once your code is error-free, then you'll be ready to tweak it to meet your needs.
If VBScript is a subset of Visual Basic for Applications (VBA), and VBA is a subset of the full Visual Basic package, it stands to reason that there just isn't as much that can possibly go wrong or need improvement when you're creating your code, right? Yes and no.
Being a subset of any language definitely means that lots of the problem-causing elements are missing, but it also leaves adventurous developers in search of a way to implement a function that just isn't there. The classic "just sit down and code around it" method may or may not work, depending on just what it is you're trying to sneak past the interpreter, but it may certainly make some tasks a lot harder than they might otherwise have been. What do come into play are many of the same tips and techniques that programmers have been availing themselves of in Visual Basic for a number of years now.
With so many ways to address informational components, such as the text in an HTML form element, you might not be too concerned about what methodology you use. You could directly reference the element through a unique name in a statement such as newtext = MyText1. Text, or you can use any combination of Form.Element.Property or Document.Form. Element.Property to recurse your way through different levels of naming. If you're going to be using that property several times, though, you're better off storing the data to a variable in memory, and then referencing that data in the form of a variable later. As an example, Listings 11.4 and 11.5 show two different ways of attacking the same use of data from a form's text input element (named Department) inside a form named UserForm1. While both snippets of code would work inside a real VBScript function, Listing 11.5 uses variables, and would end up being faster. Note that the code examples aren't complete working VBScript programs, just small parts of a larger application.
Listing 11.4. Using Document references instead of variables.
1: Sub Btn1_onClick
2: if (Document.UserForm1.Department.Text = Human Resources) then
3: {
4: call HRValidate(Document.UserForm1.Department.Text)
5: }
6: if (Document.UserForm1.Department.Text = Engineering) then
7: {
8: call EngValidate(Document.UserForm1.Department.Text)
9: }
10: if ....
11: end sub
Listing 11.5. Using variables instead of Document references.
1: Sub Btn1_onClick
2: Dim dept = Document.UserForm1.Department.Text
3: if (dept = Human Resources) then
4: {
5: call HRValidate(dept)
6: }
7: if (dept = Engineering) then
8: {
9: call EngValidate(dept)
10: }
11: if ....
12: end sub
Besides making the code more readable, the use of the variable dept substituting for Document. UserForm1.Department.Text reduces the underlying number of recursive and repetitive object calls, significantly improving overall performance. This type of optimization is very important when dealing with looping structures like While...Wend and For...Next loops. Storing the value of a property in a variable and then incrementing that value using a variable is much faster than retrieving data from the property each pass around the loop. One of the great things about objects is that they internally store all the functions that can be used to modify them. This code makes data corruption impossible because the object knows exactly what it wants. However, depending on the quality of the code, getting the text property of an object consecutively can take much longer than getting the property once and then maintaining it in a variable. The extra layer of code that makes objects safe and secure can also make them much more cumbersome for fast operations.
One of the most convenient reductions present in VBScript is that of the single data type- the variant. Instead of Diming strings and integers all over the place, VBScript considers all data to be more or less generic. When you begin to use outside functions, such as those in ActiveX controls, you can certainly continue to use the variant data type to pass information to controls, and then have them convert it, but it's often more efficient to use the built-in data conversion routines that VBScript provides, saving one more step. It is a good idea to use functions like Cint, CLng, and Csng and VarType to check the values that your variants contain. An even better way of keeping track of the types of variables you are using is to standardize your variable name declarations. Use a prefix that describes the data type in the name of the variable as you define, so that in the future you are able to easily identify the type of data you are referencing.
For example, if you want to store the state of a particular control property as a Boolean, you can define your storage variable as blnButtonState. The prefix that you use in the variable name will help you determine just what type of data you will expect to find inside. If you are trying to store currency information for a banking application in a variable, make sure that all of the variables dealing with funds are prefixed with cur. That is, CurTotal will hold the current total for a user's account with the currency data type. There is no hard and fast standard for this, so work out what works best for you.
Optimizing ActiveX controls is roughly equivalent to trying to compress a brick. They're self-contained and precompiled, and you have only a certain amount of control about the way they handle things. What you do have control over is how you use them, both in quantity and functionality.
Before you run out and place every ActiveX control ever made into the HTML on your page, consider the lowest common denominator for connection speeds and download times. If your Internet connection comes in the form of a T-1 line, a 200KB control is an insignificant amount of download time. If you're on ISDN or a dedicated 56.6KB line, controls around 100KB aren't excessive. If you're on a 28.8 modem, or stuck on a 14.4, file sizes start to become extremely important. Having recently downgraded from a T-1 line, we can tell you from experience that people on slow connections won't be too thrilled about waiting a minute or more just for text animation or a PowerPoint slide show.
The task you're faced with is minimizing the supporting files you need in order to get the functionality you want. This often involves a good deal of research, and a bit of design brainstorming. Do you take the chance that someone has a specific control, or is this page's primary duty speed of display and response? Do you embed an Excel spreadsheet, or do you convert the file into an HTML table? You have to make the decisions as to where a change is necessary for speed, and where such a change would detract from functionality and appearance. But sometimes you can make things easier on yourself.
If you look at some of the ActiveX controls out there, you'll notice that there are a variety of different ways of getting a particular task done. While a number of individual controls could be downloaded, the HTML Layout control contains a bunch of useful controls all bundled together. Although you might not need them all, you might need two or three of them, and it's more efficient to download the one CAB file and have it installed than it is to initiate multiple downloads and installations, as long as the single CAB file isn't more than about 30KB bigger than the individual controls.
The trick is to see where one control can serve multiple purposes, and where a control could be replaced with clever (but efficient) coding. Do you need an Image control, or can you get by with an animated GIF? Don't skimp on functionality, though. If you need control over an animated image, you need ActiveX controls to do it. If you have large sequences of images to display, you could end up being better off to start up an ActiveMovie control and stream the images as AVI, controlling their playback rate. It's all a matter of give and take.
Remember that speed on the Internet is relative to the amount of data that must be sent over your network connection. The fastest code in the Internet is the code that makes it from your Internet service provider to your local machine in the shortest time. Deadly wait times while a program is downloading can make an early end of an ambitious project. It may actually be a good idea to divide your application into smaller segments and have the user navigate between HTML pages. This keeps the download time at a minimum between parts of your application and will give the best response time to your users who only have 14.4 modem connections. Because VBScript programming and HTML code is realistically just pages and pages of text, the less text you have to transfer, the faster your application will be downloaded to the local machine and processed. Try to keep your applications as tight as possible without giving up your standards. Keep in mind that making your users navigate a little more to get where they are going can often be seen as a higher level of interactivity.
Creating interactive applications can be easy or hard, depending on the tools you have available to you. Developing with VBScript and ActiveX was, like anything else, not a walk in the park when it first came out. But even just a few months after you catch on, a number of options exist for you to get the job done.
Okay, there are a lot of us out there who just refuse to "modernize" certain aspects of our development process. I'll admit to being one of them when it comes to things like HTML page creation, and wanting to do HTML coding all "by hand," instead of relying on someone else's stab at what everyone wants in an HTML editor. If you know the syntax, and type pretty fast, your run-of-the-mill text editor (like Notepad, the old standby) can crank out some useful stuff pretty quickly, and on any system you choose. No quirky development environments, costs, or cryptic interfaces... just you and a heck of a lot of text.
While the romance and mystique of the text-editor-using code-creating guru may be something you want to continue to inspire in public, don't be too resistant to certain changes. Advanced interactions, such as those between VBScript and ActiveX controls, require the entry of dozens of parameters and incredibly weird sequences of numbers, which you really don't want to try to memorize, do you? Microsoft likes to call them Globally Unique Identifiers (GUIDs), but you can just call them a pain to type in.
Each ActiveX control has a GUID in the form of a ClassID, which tells the client system a lot of things about the control and allows the system to check and see if it has it on hand. If you're up to the task of memorizing 32-bit numbers for every control you plan on integrating, and you would rather type those sequences by hand every time you use each control, you can consider yourself a pretty die-hard ASCII editor fan. You'd also be very wealthy if you got paid by the hour for that.
The next rung up the evolutionary ladder of coding is the ActiveX Control Pad. While not really an Integrated Development Environment (IDE), it does take the first step toward making development easier, and the Control Pad is free. Both of those weigh heavily in its favor, no matter what kind of quirks or drawbacks people may associate with its use.
The Control Pad provides a toolbox for putting together the most commonly used pieces of your HTML page. Objects, properties, positioning... they're all there for your benefit, if you're willing to give it a try. If you don't know the ClassIDs of the objects you were planning to use, it cuts the time even more significantly. By the time you hunt through and look up the ClassID for use with a text editor, you could have placed three distinct classes of objects on your page with Control Pad.
Going even further in optimizing your development time, you can take an existing Visual Basic application and convert it, or the majority of it, to VBScript. The first publicized tool of this sort, VBNet, came out at the time of this writing. It takes existing Visual Basic applications and converts them into VBScript-based applications instead-at least mostly. There are two conflicting schools of thought when it comes to applications like this, because of one simple fact; since VBScript is a subset of a subset of Visual Basic running in a special environment, not all applications (and certainly not all functionality) can transfer from the original application. On one hand this leaves developers saying, "Well, if it can't handle my specific function, then what good is it?" But on the other hand, it makes a large number of other developers smile because it does at least some of the work for them.
The most important thing to do when considering conversion is to take a long, hard look at the original application, and see what kind of functions it needs. File I/O and a pile of other common functions will either end up requiring links to a server-side CGI program or the use of ActiveX controls. Remembering the earlier discussion on download times and the number of controls being used, this could be a problem.
For the moment, treat Visual Basic to VBScript converters as a good step to getting rid of the basic time-consuming steps, but definitely short of a fully optimized and fully functional porting tool. There's no doubt that the tools that currently exist will improve, and that future tools will continue to fuel the competition for the most effective converter on the market. But don't bet the farm on the perfect tool... be prepared to do some of the conversion tune-up yourself.
Is there a real Integrated Development Environment in VBScript's future? Considering the market that Microsoft is trying to push VBScript into, the sheer number of possible users would seem to be too lucrative for some developers to pass up. As other applications and corporations decide whether to begin hosting VBScript in their applications, each may end up with its own special integration and specialty interfaces.
With Visual Basic 5.0, Visual Basic for Applications, and VBScript to consider, Microsoft may well end up turning Visual Basic into an all-purpose IDE that could use a project wizard to make anything from a full-blown Visual Basic application all the way down to the simplest of VBScript functions. Embedding a Visual Basic/VBA to VBScript converter wouldn't be a bad thing either, considering that they would have an instant inventory of what ActiveX controls were available to provide necessary functionality. While VBScript may be free to the public, rest assured that Microsoft will certainly aim to make a profit from related components, as will countless other developers.
The right amount of optimization is the amount that feels comfortable to you. You don't want to spend all your time tweaking something when there won't be any discernible improvement, but you shouldn't leave code up that could be significantly improved. Since your VBScript source code is there for the world to see, it's their first indication of your work, and they get to see it all, from the organization to the finished results. You only get one chance to make a first impression.
As you begin to integrate more advanced functionality, make sure that you standardize as much as possible. If you have ever worked in a workgroup environment, you know what it is like to look at someone else's code and have absolutely no idea how they got where they are going. A good set of rules set at the beginning of a project and followed through to completion will get your work out the door faster and make your code reusable. There may not be much that you can do to increase VBScript performance-wise, but the performance of your application can be greatly dependent on how it is maintained and reused. A lot of unnecessary hacking into a program to fix undocumented problems will definitely cut back the efficiency of your work.