At the height of the Industrial Revolution, two workers watched with awe as a huge backhoe rapidly scooped up tremendous amounts of earth.
"If it wasn't for that blasted machine," said one worker, "there could be five hundred of us working here with shovels!"
"That is true," replied the other, "and if it wasn't for our shovels, there could be a million of us working here with spoons."
The ever changing landscape of technology has repeatedly introduced new means of automating the labor-intensive tasks of the previous generation. This has, of course, given rise to the seemingly perpetual conflict between business owners, who see automation as a means to higher profitability, and labor forces, who see automation as a means of making a large number of workers obsolete. One of the greatest concerns is that the automation of a manufacturing process, for example, transfers the hard-earned skills of a group of workers to a machine. With the machine, the same process can be carried out without those skilled workers. In general, the automation of a task allows the same task to be performed by fewer people with fewer skills.
Leaving the subject of labor issues to sociology texts, we can at least acknowledge that because an automated task requires fewer skills to perform, a much larger number of people can effectively perform that task. Once automated, a task that was the privilege of a few becomes a possibility for all. Call it freedom and democracy.
As an example, consider 35mm photography. When 35mm single-lens reflex (SLR) cameras first appeared decades ago, only a small number of expert photographers actually knew how to manipulate the controls necessary to produce a good photograph. As time passed, tasks such as measuring available light or synchronizing a flash to the click of a shutter became automated and integrated features of the camera. These simplifications opened 35mm photography to a much larger number of people. In the past 20 years, other camera operations have become automated: film wound with a motor drive, exposure determined with integrated shutter and aperture control, focus accomplished with auto-focus lenses. In the 1990s, computers with large memories have become small enough to fit inside a camera. At the time of writing, those computers have integrated the expert advice of hundreds of professional photographers and the experience of a hundred thousand lighting situations to the point that high-quality 35mm photography has become nearly idiot proof. Good thing, too, because there seem to be a lot of us idiots out there, a good number of whom are using computers as well.
The history of the computer is also riddled with new automated technologies. Operating systems have automated the task of managing a computer's resources. Programming tools have automated the task of turning high-level languages into machine code, and more recent tools have even automated the task of writing programs in high-level languages.
Personal computers have been a tool in many homes and offices for some years now, and end users are becoming more mature and more comfortable with what computers can do for them. A few short years ago, many users found that they frequently repeated the same sequence of operations within a particular application, and they wanted a way to automate those sequences. This spawned the idea of macro programming, by which the user could list the steps in a sequence and essentially make the sequence a single operation in itself, called the macro. That single operation could then be attached to a keystroke or other command-giving device. Within corporations, instead of each end user creating his or her own macros or custom solutions, corporate developers usually do the job. The result is consistency in the execution of tasks (fewer errors) and more overall productivity—workers can concentrate on the business task, not the operation of a computer application.
More recently, end users and corporate developers have been finding that many of the macros they want to create involve multiple applications. For example, once a month someone might want to take raw numbers from a database, perform calculations on them in a spreadsheet, color a regional sales map with the results, place that map in a word processor document, and send a report via e-mail to the company's nationwide sales manager. By automating this task, one person could give the appropriate command on the last day of each month to generate the report, instead of having a dozen people spend a frantic week doing the same thing manually. Furthermore, if you could somehow rig an alarm clock control to automatically give the command on the right day of each month, even the person assigned to give the command could be freed from that chore.
OLE Automation, or just Automation with a capital A, is Microsoft's technology for solving the problem of cross-application macro programming, but it goes much deeper than that. In the past, Microsoft explored the idea of building a standard macro-programming language and programming tool into Windows itself. In a country built on free-market economics, this was a wretched idea: it would have limited the choice of macro-programming languages to one and the choice of tools to one. Instead, Microsoft chose a more open path and created OLE Automation, in which components with shared functionality or content become automation objects, and clients that can integrate those objects become automation controllers. Because Automation is a protocol, any automation controller can use every automation object, and any automation object can be integrated with every automation controller. Thus consumers—end users and corporate developers alike—can be given a full range of choices. Microsoft, of course, has produced its own set of automation objects (components contained in Microsoft Office applications and others) and its own set of controllers (centered around the Basic language in Microsoft Visual Basic, Visual Basic for Applications, and Access Basic).
This lengthy chapter will look at the mechanisms that make Automation work and then examine the design and implementation of automation objects. In the implementation section, we'll see a number of different ways to implement a simple object, and then we'll look at automating an entire application with a hierarchy of objects, using the version of Cosmo from Chapter 12. This latter section also includes a few design notes, and I want to stress that even if you do not intend to automate an application today, you may still want to read this information to get a sense of how you can structure your application to make it readily adaptable for OLE Automation later.
The architectural part of this chapter is quite long, so you may find it best to skim these sections and then follow through one of the samples under "Five Variations on the Theme of Implementing a Simple Automation Object" before coming back to reread more of the earlier material. I warn you against any attempt to pick up Automation in one sitting.
In this chapter and in Chapter 15, we will see that Automation has only a few interfaces and a few OLE API functions. So why is this chapter one of the longest in this book? The reason is that through the single IDispatch interface, a client can access a tremendous amount of functionality and content. Accordingly, IDispatch is a very rich interface, and it will take a while to look at all the details. In doing so, we'll see that the implications of OLE Automation for application design and the possibilities that it creates can be tremendous. Like automation in other industries, the automation of working with software can significantly change the nature of how people perform tasks. OLE Automation is really the software equivalent of beating spoons into shovels and shovels into backhoes. Then we can figure out what to do with the backhoes.
In order to test an automation object, you generally need an automation controller. For most of the samples in this chapter, the AutoCli sample in Chapter 15 serves well. Otherwise, you can use Microsoft Visual Basic (version 3 or later) using the projects in the CHAP14\BEEPTEST and CHAP14\COSMOTST directories. In addition, the 16-bit OLE SDK included a tool named DispTest, a stripped-down version of Visual Basic 3. Note, however, that both DispTest and VB3 are 16 bit only, so you cannot use them to test a 32-bit object—automation is subject to the limitations of Local/Remote Transparency between such models. If you're working on a 32-bit platform, a later 32-bit version of Visual Basic will run with 32-bit builds of this chapter's samples.