News

by Ron Petrusha
10/01/1999

In the late 1980's, Bill Gates announced that Microsoft was committed to developing a "universal batch language" that could be used across all applications to automate basic system and application processes. This vision was met with considerable scorn from skeptics, who continued to scoff as Microsoft frequently delayed a release for this scripting language. That was then.

Today, many believe that Visual Basic for Applications (VBA), the programming language first included with Microsoft Excel in 1993, represents this long-awaited universal batch language. VBA has since been extended to the other members of the Office family and a few 3rd party applications such as AutoCAD and Visio. In reality, Microsoft has silently abandoned its quest and instead has begun to promote the notion of language independence--that is, that the developer can write an application in the language that he or she knows and feels most comfortable with.

Depending on the language(s) available within a particular programming environment, it doesn't really matter whether the programmer uses C/C++, Visual Basic, Visual Basic for Applications, VBScript, JavaScript, PERL, Python, Rexx, or any other language. This seems like a rather peculiar way of offering a universal batch language--it really makes the language a matter of complete indifference. And indeed, that's the case. From the Microsoft viewpoint, a batch language is nothing more than glue designed to hold the pieces, or components, of an application or routine together.

But if the language is a matter of indifference, there must be some common feature that allows a language to glue components into a single script or program. And indeed there is; Microsoft has named this common feature the Component Object Model (COM). COM is a formal specification that provides for the reusability of binary (i.e., executable) code. (Note that it differs from the source code reusability that is the concern of object-oriented programming languages like C++ or Java.) A particular COM technology, automation, allows a script or program code to access and remotely control an application or component. In other words, a language can use COM automation to access and control one or more remote applications.

Specifically, a scripting language uses COM automation to access the remote application's objects. Typically, these are organized as a hierarchy of tree-like structures. For example, the top-level Word object is called the "Application" object. It has a number of dependent (child) objects, including the "Documents" collection, the "CommandBars" collection, and the "Windows" collection. The "Documents" (note the plural) collection in turn is a container for one or more "Document" (note the singular) objects, and so on. This map of an application's objects is called its object model. Most of the objects within an object model can be remotely accessed and controlled using, as the glue, any batch language that supports COM.

Typically, a programmatic object is a virtual representation of some real-world object. A particular Document object, for instance, represents an individual Word document. But an object by itself does nothing. Instead, what is important for controlling an object programmatically are the features that the object exposes. You might, for example, want to check the spelling in a Word document programmatically. Or you might want to display a document without allowing the user to modify it in any way. In an object model, these features are implemented as properties, methods, and events.

Each object usually supports a number of properties, which represent attributes of the object. For example, a Word Window object has a "Caption" property, which can be used to either retrieve or to define the caption that appears in that window's title bar. Each Word Document object also has a "ReadOnly" property; you'd set its value to "True" to prevent users from modifying the document. Similarly, objects typically support one or more methods, which represent functionality that the object makes publicly available. For instance, the Word Document object supports a "SaveAs" method that allows you to save a document to disk. And to check the spelling of a document programmatically, you'd call the Document object's "CheckSpelling" method. Finally, many objects support events, which are fired in response to some change in the object's environment. When an object's event is fired, any code that your program assigns to that object's event is automatically executed. For instance, the Document object supports a "Close" event; if you assign code to a particular Document object's "Close" event, that code will execute by design when the document closes.

From this hasty overview of the programming using COM to access an application's object model, we can see that learning to programmatically control a particular application, like Microsoft Word or Microsoft Excel, involves a familiarity with three basic components:

1. The programming language. If you're programming Word from within Word (or Excel from within Excel), you have no real choice: Visual Basic for Applications (VBA) is the language bundled with the product, and the only programming language supported. But if you're programming Word from another application or from a development environment, you can use any language that supports COM.

2. The programming language's integrated development environment (IDE). Programmers once used a text editor to write code and a debugger to test it and diagnose problems. Increasingly, however, all programming functions (writing and compiling code, running programs, debugging code, accessing online help) are handled within an integrated programming environment (IDE). The members of the Microsoft Office suite all share a common IDE, which provides a state of the art tool for rapid application development.

3. The application's object model, which allows you to use the programming language as the glue that controls the application.

In writing this article, the goal was to introduce those not familiar with Windows programming to some of the core elements associated with the background and concepts used by professional Windows and Visual Basic programmers. Currently, O'Reilly publishes a number of books that help you put these three components together to program for the members of the Microsoft Office suite. Writing Word Macros explores Word VBA and the Word object model and provides numerous handy examples that show how you can more easily manipulate your Word documents through programming. Writing Excel Macros covers Excel VBA and the Excel object model, provides numerous utilities that show how Excel objects can be manipulated, and explores the more complex Excel objects, like charts and pivot tables, in depth. Finally, Access Database Design & Programming, 2nd Edition, examines the IDE that's new to Access 2000, explores the principles of sound database design, and shows how to get at data in Access databases using two different data access object models, Data Access Objects (DAO) and the newer ActiveX Data Objects (ADO).