VBScript-(or Microsoft's Visual Basic Scripting Edition) is a powerful interpreted scripting language that brings active scripting to a variety of environments, both client and server side. But VBScript is part of a bigger programming world-the world of Visual Basic.
What we are going to do in this chapter is to give you a peek into this bigger programming world and show you how VBScript fits in with the bigger picture. As the chapter name suggests, we'll be looking at what VBScript is and also what it isn't (this, hopefully, will dispel any myths that you might have read about VBScript).
Before we go any further, we should spend a little time clearing up a few points and getting the terminology, not just the terminology of VBScript but also that of related terminology, clear.
Windows Script is the technology that provides the backbone for scripting on the Windows platform. Windows Script itself provides two separate script engines for use within the Windows operating system:
Both of these scripting languages can be embedded and used together side by side if you want-there is no restriction on using only one language within your project, although this does make for more complex code and we don't recommend that you do this.
Windows Script also provides an array of supporting technologies that make it easier for user of Windows Script to do so. These include tools such as debuggers and script encoders.
The latest version of Windows Script is version 5.6. This is the version that we will be using throughout the book, as it is the latest, most fully featured, and contains all the latest security patches. Code written for Windows Script Engine 5.6 might work for earlier versions but cannot be guaranteed .
Version 5.6 introduced integration with Windows XP, tighter security controls, and a new object model. Windows Script has gone through many versions, each with a different host application behind it.
Microsoft Internet Explorer 3.0
Microsoft Internet Information Server 3.0
Microsoft Internet Explorer 4.0
Microsoft Internet Information Server 4.0
Microsoft Windows Scripting Host 1.0
Microsoft Outlook 98
Microsoft Visual Studio 6.0
Microsoft Internet Explorer 5.0
Microsoft Internet Information Server 5.0
Microsoft Internet Explorer 5.5
Microsoft Visual Studio .NET
VBScript is a subset of Microsoft ˜s Visual Basic. What this means is that if you are already using Visual Basic and come to VBScript you will find similarities in the syntax. The same is true if you make the leap from VBScript to Visual Basic (although you will have to learn how to use the development environment in Visual Basic). Likewise, if you come to VBScript from VB, don't expect it to look or feel too much like it. Certainly don't expect a VB-like integrated development environment (IDE) to work with. Also, don't expect to be able to do everything that you can in VB with VBScript.
However, the fact that VBScript is a subset of Visual Basic certainly makes it a compelling language to learn both as a stand-alone tool to use in day-to-day problem solving and as a language to learn that is both simple to pick up and has all the advantages of Visual Basic without the hassle of an IDE and the cost of purchasing the software.
Reinforcing their commitment to VBScript, Microsoft has released a script editor with their Microsoft Office 2003 suite.
VBScript is a scripting language, as opposed to a programming language. The difference can be vague but the key test is what happens to the source code before it becomes the end product-for example, what is actually 'run' and thought of as the program or application. The end product for a programming language is usually a compiled binary executable program, while for a scripting language the end product is still the source code. What this means is that VBScript source code and the VBScript end product are basically the same thing-a plain-text file readable and editable using any text editor (such as the trustworthy old Windows Notepad application included with all Windows versions). No special development environment is needed and the script in the file is not protected in any way.
Interpreted is another fuzzy term . It is vague because any language you care to think about can be either compiled or interpreted. This is because for any computer language you could write both a compiler and an interpreter. As long as the language itself is properly formed , all the compiler/interpreter does is make it machine-readable.
Now you might be beginning to see why VBScript is interpreted-because it isn't compiled!
Compiled means recoded into an executable format that have the .exe file extension. Programs written in languages such as C++ need to be compiled into an executable before distributed to the user .
Instead of building a compiler, an interpreter was written that takes the high-level VBScript 'source code' and interprets it as the source code is processed . The interpreter in this case is the VBScript scripting engine, which is both very versatile and easily accessible for a variety of applications.
This doesn't mean that VBScript is never compiled. All computer languages are compiled at some point, otherwise the computer wouldn't know what to do with it and how to respond to it. The language the computer uses is the lowest level possible - the 1's and 0's language of machine language or binary language. Different sequences of 1's and 0's mean different things. One binary sequence may tell the computer to add two numbers together while another sequence tells it to store a value in a particular memory address. It's pretty hard to imagine it, but everything you ask a computer to do is ultimately digested into 1's and 0's.
A long time ago, if you wanted to write a program the only option available to you was to write it in binary language. As you can imagine, this wasn't easy or convenient . Over time, more advanced programming languages were invented. With each language, more and more higher levels of abstraction were added, which meant that programmers could use syntax that was closer to that of the English language. However, while programming languages have become cleverer, computers still continue to use machine language.
Plain text is easily readable by a human (although they might not understand what it means).
Dim Counter Dim WordLength Dim InputWord Dim WordBuilder InputWord = InputBox ("Type in a word or phrase to use") WordLength = Len(InputWord) For Counter = 1 to WordLength MsgBox Mid(InputWord, Counter, 1) WordBuilder = WordBuilder & Mid(InputWord, Counter, 1) Next MsgBox WordBuilder & " contains "& WordLength & " characters."
When code is compiled, what happens is that the higher level language that the programmer understands and writes is turned into the binary language that the computer understands. The main difference between 'normal' programming languages and interpreted scripting languages is not whether the source code is compiled, but when compilation takes place. Take languages such as C and C++ that are commonly known as compiled languages, not because this distinguishes them from noncompiled languages but because they are compiled to machine code at design time (at the time the program was written).
This is where scripting languages differ . They are compiled (or, more accurately, interpreted) when they are executed, and hence runtime. This means that right up until runtime the script remains as plain text. Even during runtime, the actual file isn't altered ; all the work in interpreting it is done in memory and has no effect whatsoever on the actual source file.
Compare this to a C++ program which if you were to look at the compiled code it would make no sense at all because it as already been processed into machine language. This means that the edit-debugging cycle for scripting languages is usually shorter than that of compiled code, because you do not have to go through the separate step of compiling the code at design time. Compiled code looks nothing like plain-text script.
Here is just part of a simple piece of C++ code that does the classic 'Hello, World!'.
Not exactly bedtime reading, is it?
All the runtime interpretation of script is carried out by a scripting engine. The scripting engine is a special program that understands how to interpret the text in the script and turn that into machine-understandable commands. In this respect it is similar to any other design-time compiler, with the single exception that users never get to see runtime compilation errors of C++ executable programs, but if you make a mistake in script and don't test it, they will.
Compiling a program at runtime does bring with it a few disadvantages that are worth bringing out into the open at the beginning.
First of all, it's going to be slower. This has to be said early and there's no disputing it. This is simply because the system has to do more at runtime-it has to interpret the code. And remember that it has to do this each and every time the code is run. However, because you are not normally dealing with programs that span many thousands of lines of code, this step, albeit adding to the load, is normally quite fast.
Second, a compiled program, once compiled into binary language, is afforded protection from snooping and change. This protects both the application and the developer or company that owns the code. Curious users or malicious hackers cannot read the code to find out how things work, make changes, or ' borrow ' code for their own applications. Because a script is plain text, it isn't afforded such protection and anyone who can gain access to the file can read it and make changes.
Some will argue that this transparency of code is what has made script so popular (in the same way the ease in reading and making alterations to Web pages made HTML a huge success). Transparent code makes it easier for others to find it, read it, copy it, and ultimately learn from it.
Later on in the book we'll be examining ways that you can protect your intellectual property from unwanted snooping using a variety of techniques.
Finally, when you compile code at design time you can catch and debug any syntax errors you come across, whereas syntax errors in script aren't caught until runtime. Remember that even expert programmers make syntax errors occasionally when they write code. It's human nature. The design-time compiler or runtime script engine expects you to write code that follows stringent rules of syntax. You must do things right. You can't misspell variable names or have ambiguity over parameters passed. Everything has to be right. And even if you are an expert, simple typos can creep in and wreak havoc. The more complicated the code, the more likely it becomes it will contain a mistake-accept this and plan accordingly . What that ultimately boils down to is one word-testing. Test all code and never rely on thinking that it looks OK or the fact that it worked last time. Script errors when seen by the end user reflect badly on the programmer.
With the downsides come the upsides. Here are the advantages of using script over compiled languages.
One of the main advantages of script code being plain text is that it can be embedded with other types of code, for example:
Here is a simple example of VBScript code incorporated into a simple HTML Web page.
Click Me If You Can!!!
Even if you don't know much about VBScript just yet, you can probably understand what this code does ( easiest way for you to figure it out is type the code out into Windows Notepad, save it with a .HTM file extension and run it in Internet Explorer).
In the same way you can mix script, HTML and XML (a markup language that handles data structure) in another file. These files can then be downloaded over the Internet in a Web browser where it is executed. If you want the same level of flexibility in a compiled language, it would be very hard (or at least expensive) to achieve.
Scripting is ideally suited for quick, ad hoc solutions. For example, say you wanted to write a small application to back up certain files stored on a hard drive. This is an ideal job for script. Of course, you could do the same job by hand but if the task was one that was going to be repeated on a regular basis, then an automatic solution would be faster and more accurate. Creating a simple script to solve such problems can be much faster and easier than doing the same thing in a compiled language. Also, compiled solutions would take up greater disk space and would not be platform-independent.
Finally, because scripting does not require a complicated IDE, such as those required to program with Visual Basic and Visual C++, scripting languages are easier to learn.
Scripting can be an excellent gateway into the vast, exciting, and lucrative world of programming. Scripting languages are much easier to learn and far more forgiving to mistakes than do compiled languages, and they are great for solving simple tasks . Also, because VBScript has its roots firmly in the BASIC programming language, it is especially quick and easy for the nonprogrammer to pick up and begin using.
There are other advantages to using VBScript as a programming language:
How do you know if VBScript is right for you? In fact, it's just answering a few simple questions should help you come to the right decision.
But how do you know if VBScript is the right tool for you to be using? Faced with many different programming languages to choose from, it can be hard to come to the right decision, especially if you don't understand the capabilities of each language.
Fortunately, it's easy to find out if VBScript is the right choice for the project you have in mind. For example, VBScript isn't for you if you want to end up with a compiled executable program, if you want to make extensive use of file I/O, or if speed or graphical manipulation is important to you.
This isn't an exhaustive list by far, but it does cover the areas of programming best left to another language. However, this isn't to say that VBScript can't handle graphical manipulation or file I/O-it can do both-it's just that it's not ideally suited to those applications and other languages exist that can do the job much better. This doesn't reflect badly on VBScript in any way, it's just a case of using the right tools for the right job.
For example, VBScript is for you if you want to quickly prototype code, you write code to carry out repetitive processes (such as backup or deleting files) or administrative functions (such as registry tweaks), you want to use ASP, you are a Web developer who builds Web pages aimed at Internet Explorer users either on the Internet or Intranet, or you are developing an application and want to include scripting support for it.
VBScript (sometimes referred to as VBS), Visual Basic for Applications, Visual Basic (VBA), Visual Basic-what's the difference between them all?
Let's begin by taking a look at Visual Basic. VBScript and VBA are both subsets of Visual Basic itself, which is a stand-alone, hybrid language (that is hybrid between compiled and interpreted.), complete with its own IDE. This IDE includes all the things you'd expect of an IDE-language editor, form designer, debugging tools, code project managers, controls to integrate into applications, wizards, and so on, to aid the developer. Visual Basic provides a full set of language features and includes the ability to access the Windows API, allowing VB applications to access key functions of the Windows operating system.
Is it a hybrid language? It's not accurate to call VB a compiled language. It is more of a hybrid between a compiled language and an interpreted language. Applications written in VB are indeed compiled, but they rely on a very large 'runtime library' to work. This runtime library consists of a set of DLL files ( Asycfilt.dll , Comcat.dll , Msvbvm60.dll , Oleaut32.dll , Olepro32.dll , and Stdole2.tlb ) that have to be installed on the system that wants to run the VB application. This isn't a big problem because the program that builds the installer includes these files; the problem is just that even the smallest VB application distribution becomes bigger than 1MB when these files are included. This situation is changed in Visual Basic .NET (VB.NET) with the introduction of the Common Language Runtime Framework.
Let's add another bit of confusion. Although VBA is considered a subset to VB based on the functionality that it offers, VB actually uses VBA at its core because the VBA library defines both the VB language itself and allows other applications (such as Microsoft Word) to host Visual Basic capabilities. So you could look at the Visual Basic IDE as just another host.
Visual Basic for Applications is an 'embedded' version of Visual Basic. VBA allows developers with an existing application to provide a powerful tool to enable customization and extension of the application. The biggest and best example of this is the Microsoft Office suite of applications, Microsoft Word, Microsoft Excel, Microsoft Outlook, and Microsoft Access. These applications all support VBA and come fully equipped with a VBA IDE similar to that provided by VB Using the VBA IDE you can write code that goes well beyond the basic features offered by these applications and design custom tools to handle pretty much any job you want carry out.
VBA is quite fast, but not as fast as Visual Basic. VBA code is compiled by the host application into interpreted P-code in a similar way that VB version 4.0 and earlier was capable of.
The main thing to remember here though is that VBA can only live and work within the host applications. You can't write a small application in VBA, distribute it, and expect it to work stand-alone. Neither can you distribute a whole Microsoft application with it! VBA is irrevocably bound to the host application. You can, however, distribute VBA to others who have the host application, but you must bear in mind that the hosts must be the same to ensure all functionality is present. There would be no point, for example, distributing VBA code that worked on a spreadsheet and expect it to work in a word processor.
Syntactically, VBScript is similar to both VB and VBA. If you've used either before, the syntax that we use in VBScript code should be pleasantly familiar to you. However, it is quite different in other important respects.
Many people worry about this needlessly. They have heard or read that serious C++ or VB developers don't think that VBScript, or any scripting language, is 'real' programming, and as such isn't worth learning. This is absolutely wrong. It's just a matter of picking the right tool for the job. If you were going to develop a new word processor, Web browser or accounting system, choosing VBScript as the main tool would be unwise for a variety of reasons. However, including VBScript support in that application, so that the end user might automate repetitive tasks would be a major bonus. Also, let's face it, it's not every day that you want to write something major. Sometimes programming skills come into play to solve much smaller problems, which is where VBScript can come in useful. Also, try embedding C++ code into an HTML or ASP page-that's not going to work, no matter how 'real' you think it is.
The basic fact of the matter is that Microsoft didn't come up with VBScript as a replacement for all other development tools-although a free tool that did that would be cool. VBScript is designed to supplement and augment other languages and to provide a low-impact, easy solution to some tasks while leaving the big stuff to the more powerful languages.
Think of VBScript as an important tool in today's programmer toolkit and you won't go far wrong.
VBScript is a powerful language, but on its own it can't do anything. In order to make it do something you need a host because the code itself isn't compiled. As we've already mentioned, a host is an application that can interpret, compile, and execute plain-text VBScript code.
The Windows Script Host (WSH-previously called the Windows Scripting Host) is just one host that allows you to run VBScript. This host allows you to run VBScript directly from within the Windows operating system. The concept of WSH is similar to that of the DOS batch file or Unix Shell scripting. You can also choose how these scripts are run:
WSH is perfect for a variety of common network and administrative tasks , such as making registry changes and creating network logon scripts.
The great thing about WSH is that you can run script just as simply as you run any other program installed on the system. It looks just like any other compiled application to the user , but under the hood it is powered by script.
WSH also comes complete with a set of objects that allow the programmer access to the Windows file system and environment.
WSH scripts don't have to be written in VBScript. In fact, any language that conforms to the ActiveX scripting specification can be used. This includes, Perl, Jscript, and Python.
WSH is the perfect way to try out many of the code examples that appear in this book. Remember though that some scripts will depend on certain hosts . For example, client-side Web scripts will require Microsoft Internet Explorer browser while Active Server Pages (ASP) script will need Microsoft's Internet Information Server (IIS) or Personal Web Server (PWS) or equivalent to run. WSH is supported on all Windows operating systems from Windows 98 to Windows XP.
A Windows Script Component (WSC) is a COM component that combines XML with script code. These are run server side and can perform a variety of tasks, such as performing middle- tier business logic, accessing and manipulating databases, adding transaction processing to applications (in conjunction with Microsoft Transaction Server), and used to add interactive effects to a Web page in conjunction with DHTML Behaviors.
Previously, this level of control and application was only available to C++, Visual Basic, and Delphi developers.
Client-side Web scripting is probably the VBScript host that offers you, as the developer, the greatest reach in terms of potential users. Web use is on the increase daily and now even the simplest HTML page often contains script code. The script code in HTML pages is downloaded into the browser with the corresponding HTML code that defines the structure of the page (and any CSS that might be used for formatting). This code is then interpreted by the visitor's browser.
Script can not only be used to make Web pages look compelling to the visitor to the site but can also be used to add functional features to a page, help to reduce server load and page load times, and maximize on bandwidth.
Server-side Web scripting is done using ASP pages. These pages are HTML pages that contain specially formatted script code.
This, unlike client-side script, is then processed at the server when a request is made for the page and the output is sent to the browser that made the request. Pages created with ASP can, just like ordinary HTML pages, contain script that is processed client side by the browser.
The host for ASP is installed on the server. In order to take advantage of ASP on the Internet you will need access to a server running an appropriate host, such as IIS.
Here is a simple ASP example (don't worry about what it means just yet. In fact it is a simple ASP-based counter for a Web page).
<% Set FS=Server.CreateObject("Scripting.FileSystemObject") Set RS=FS.OpenTextFile(Server.MapPath("counter.txt"), 1, False) fcount=RS.ReadLine() RS.Close fcount=fcount+1 Set RS=FS.OpenTextFile(Server.MapPath("counter.txt"), 2, False) RS.Write fcount RS.Close Set RS=Nothing Set FS=Nothing %>
This page has been visited <%=fcount%> times.
However, if you don't have access to an ASP capable server, you can always download PWS for Windows 95, Windows 98, and Windows Me or Install IIS on Windows NT, Windows 2000, and Windows XP Professional. Using this you can develop your own ASP and view them in any Web browser you have installed on your system.
Remote scripting is a technology that allows you to treat all ASP pages as if they were COM objects. This allows the client to 'call' scripts that are embedded in ASP pages on the server. This means you can allow scripts to be run server side as if they were client side. The advantage of this is that large, complicated code doesn't have to be downloaded to the user's browser, speeding up the process as well as protecting any proprietary code from prying eyes and alteration.
An HTML Application (HTA) is a Web page that runs in its own window outside of the browser window. This offers many advantages over running a script from within the browser itself:
HTAs run outside the browser and as such are considered 'trusted' and are subject to different security constraints.
HTAs can be used to build stand-alone graphical applications that may be run without the need for a Web server, network, or Internet connection to work.
HTAs are likely to be of great interest to WSH programmers who were previously limited to using pop-up dialog boxes to communicate with the user, instead enabling them to create an effective interface using HTML.
Imagine wanting to give users of your application the power to automate general functions within that application using a simple-to-learn scripting language. Would that be something you'd be interested in? How much would that be worth to you? Read on if you are interested.
Adding the ability for the user to be able to control and customize an application using script is a compelling one. Adding a solution that has been designed in-house is one possibility, but that is likely to be difficult and probably second rate. Now, Visual Basic, C++, Delphi, and other developers can add VBScript support directly to their applications using the free Microsoft Script Control (MSC). Adding the MSC adds support not only for VBScript but also for JScript, Perl, and other ActiveX-enabled scripting languages-all by adding a few extra lines of code to the application. The ActiveX control you need (the Microsoft Windows Script Control) is freely available for download from the Microsoft site at http://www.microsoft.com/scripting . And don't think you have to download a massive component-the current file size is just 205kB. It is supported in Windows 98, Windows Me, Windows 2000, and Windows XP.
The Windows Script Control is currently available only in the English and German languages.
We've already said that VBScript has no development environment; so, what tools should you use for VBScript?
Well, if you don't want to spend money on an editor, just use plain old Windows Notepad that comes with every install of Windows. It's fast, easy-to-use, and reliable and does the job just fine. However, it's primitive and not customized for any specific coding or scripting application.
So, if you want more, you might have to spend a little cash (depending on what you choose). There are literally hundreds of text editors on the market that allow you to edit text and a lot more. Some come with advanced clipboard control, auto-indenting, color -coded syntax, auto-backup, and many more functions.
Here are a selection of editors-some free, some shareware, some commercial-that exist. Any would be ideal for VBScript writing and the final choice you make will be based on personal preference.
IDM Computer Solutions, Inc
Programmer's File Editor
Helios Software Solutions
EditPlus Text Editor
If you don't like any of these, then fire-up your browser, log on to your favorite search engine or shareware site, and start looking! There are literally hundreds out there, so take your pick!
Now that you've read this chapter you should have a pretty good idea of what VBScript is, what it isn't, and how VBScript fits in with the Visual Basic family of languages. We've also introduced the VBScript hosts that you can use and touched upon the fact that if you develop applications in another language you can add VBScript support to them for free.
Well, now you've had a brief introduction to programming and taken a tour of VBScript, it's time to take a look at the detailed nitty-gritty of the language, beginning with variables and data types.