1.3 Putting Automation to work | Microsoft Office Automation with Visual FoxPro

Putting Automation to work

Two applications are involved in any Automation session. The application that s in charge (issuing the orders) is called the Automation client (or just client). The application that s being manipulated is the Automation server (or just server). The client addresses an instance of the server as if it were any other object, reading and setting properties and calling methods. This simple technique means that a Visual FoxPro application (the client) can address anything from the Office applications to Windows file system to Lotus Notes to all kinds of other things. In fact, VFP itself can be used as an Automation server.

To get started, the client creates an instance of the server application. (See the various "Basics" chapters in the product-specific sections of this book for details on how to do so for each of the Office applications.) Internally, when a client attempts to instantiate a server, Windows goes off to the registry and says, "Help! Somebody wants to create such-and-such server." The registry looks up the server by name and then finds out what program it is and where that program is stored. Windows executes the program in question (assuming it finds such an entry in the registry and finds the specified program where it s supposed to be). It then returns a reference to the newly executing program to the client, which hangs on to it so it can find it again later.

Obviously, there are lots of places along the way where something can go wrong. The server name might not be found in the registry, the program might not be found where it s supposed to be, there may not be sufficient system resources to start the program, and so on and so forth. If anything goes wrong, an error is raised and the server fails to start. (See Chapter 14, "Handling Automation Errors," for ideas about what to do when that happens.)

However, if all goes well, the client has a reference to the server and can start ordering the server around. It s like being in a restaurant once the waiter has introduced himself. You know his name, and you know what he looks like, so you can call him over when you need him, and you can start telling him what to do. Except for one thing. You don t know what s on the menu. You can make some educated guesses based on what the place looks like. For an application, that corresponds to guesswork based on which application it is and what you know it does. But to use the restaurant efficiently, you need the menu. To work with the application server efficiently, you need to know what it can do. Chapter 2, "The Office Servers," examines how to find the menu for an application server.