Ron,

VBScript includes?

Matt

Matt,

At first glance, you may think that this is a sentence fragment (VBScript includes what?), and perhaps that this week's column will decry the decline of writing skills in today's world, caused, no doubt, by an excess of television and surfing the web. After all, that only seems appropriate for a book publisher. As it happens, though, the question concerns VBScript's support for include files, and I think that it's a really interesting one.

If you're a C or C++ programmer, you are sure to know what include files (also known as header files) are. In fact, it's difficult to imagine C or C++ programming without them. They're used to store type definitions (the equivalent of the data types defined in Visual Basic using the Type... End Type construct), constant definitions, and prototypes for functions defined in libraries as well as in a project's source code. In short, by containing the definitions of objects and data types that can be used in multiple projects, they make an enormous contribution to the cause of structured programming and robust, reusable code.

At least some Visual Basic and VBA programmers have been arguing for support for an include statement for a long time. This is one feature, though, that Microsoft has steadfastly refused to implement, and for good reason. Much of the explanation for this, of course, is that the modular character of the Visual Basic or VBA project by its nature supports included files, even though an include statement isn't present in the language and even though the files themselves are not known as header or include files. But the ability to add the same code module or set of code modules to multiple projects forms a very definite method of source code reuse. The difference here is one of terminology and implementation--of form rather than substance. In C/C++, the #include statement is used to add a reference to a header file. In VB or a hosted VBA environment, a shared code module, class module, or possibly even a form file can be added to a project.

Scripted applications, however, lack the VBA integrated development environment, which means that the medium that makes shared source code almost transparent is absent. This would seem to leave support for included files up to the VBScript language--and VBScript itself completely lacks any statement or language construct that remotely corresponds to the C/C++ #include statement.

Currently, scripts written in VBScript can run under four different environments in Windows. They are:

• Microsoft Internet Explorer. Because VBScript is not supported by Netscape Navigator, this is the least popular form of scripting with VBScript. (JavaScript is most commonly used for client-side scripting.)

• Microsoft Outlook. Although Outlook 2000 for the first time supports VBA at the application level, all version of Outlook to date use VBScript as the programming language for Outlook forms.

• Active Server Pages (ASP). ASP is an ISAPI filter that allows server-side scripting for Microsoft Internet Information Server. When an ASP script executes, it either provides some backend service (such as updating a database based on user input) or generates either HTML or client-side script to include in the output stream send to the client.

• Windows Script Host (WSH). WSH is the long-awaited scriptable object model for the Windows family of operating systems that replaces the increasingly defunct DOS batch language.

This doesn't mean, though, that included files aren't supported in a scripted environment that uses VBScript. It means, instead, that support for included files depends on the way in which the individual scripted environment is implemented. Of the four scripted environments, two--ASP and WSH--support included files.

ASP's support for includes comes through the #include preprocessor directive. This is an an include statement in the traditional meaning of the term. The contents of the included file are simply inserted into the text stream when ASP is parsing a page for server-side script. The syntax of the #include preprocessor directive is

‹!-- #include PathType = sFileName --›

where sFileName is a string containing the path and filename of the included, and PathType is either of two keywords that indicates how the path component of sFileName is to be interpreted: File indicates that it is a relative path from the current directory; Virtual indicates that it is a full virtual path.

Note that the #include directive has to be surrounded by HTML comment symbols; otherwise, the text of the included file will appear as text in the HTML output stream.

As of version 2.0 (which is now in beta and can be downloaded from msdn.microsoft.com/scripting), WSH also supports includes. Once again, this is a traditional include: the contents of an external script file are inserted at a designated point in the file, and the result is a single text stream that's parsed by the scripting engine. To include a WSH script file, you use the ‹SCRIPT› tag in a .wsf file so that it will be parsed by the XML parser. The syntax of the ‹SCRIPT› tag is:

‹SCRIPT LANGUAGE="language" [SRC="strFile"]›

‹/SCRIPT›

where language is the language in which the included file is written, and strFile is the name of the script file to be included. language, of course, should be "VBScript", although it can be any valid scripting language.

WSH 2.0, incidentally, includes another related (and very nice) feature, though one that stretches the definition of included files a bit. By supplying either a ProgID or a GUID to the ‹REFERENCE› tag, you can define a type library whose constants will be recognized in your script code. This is a customary feature for language tools that generate compiled code (like VB and VBA), but it's quite unusual in an interpreted environment where binding is typically done only at runtime.

I hope that I've answered the question that you intended, rather than going off on a rather long tangent. In any case, thanks for sending it in.

--Ron

Return to: Ron's Archive