Part III: More-Advanced Access Techniques
790
Using Automation in Access
The Microsoft Office applications all support Automation. Using Automation, you create object ref-
erences in your code that represent other applications (like Microsoft Word). By manipulating
these objects (setting properties and calling methods), you control the referenced applications as
though you were programming directly in them, which allows you to create seamless, tightly inte-
grated applications.
Note
The macro security settings in the major Microsoft Office products (Word, Excel, and PowerPoint) may block
access to their VBA projects to Automation servers such as Microsoft Access. When working with the examples
in this chapter, you may need to adjust the settings in Microsoft Word’s Trust Center to allow the Access
Automation code to run against Word.
Understanding how Automation works
Each Automation-compliant application (such as Word or Excel) exposes an interface that enables
the application to use Automation techniques to communicate with other applications. We never
see the interface exposed by an application — it’s only accessible by writing VBA code that attaches
to the interface and uses the resources provided by the host (Word or Excel).
A good analogy for an Automation interface is the radio in your car. Most car radios feature con-
trols that adjust the volume, station tuning, bass, treble, and other settings. Each of these controls
is connected to the internal workings of the radio. You don’t need to know anything about how
radios work in order to rock out to your favorite tunes — you just need to know how to change
the volume or tuner to a different station.
This is exactly how Automation works. An application (like Word) exposes an Automation inter-
face. The code you write in Access defines Automation objects that connect to the interface, and you
control Word by manipulating the properties and methods of the Automation objects. Applications
that engage in Automation are often referred to as servers (Word, in this case) and clients (Access).
The server provides the resources, and the client uses them.
Note
Automation is entirely a local process. You can’t automate to an application on a remote computer. All the
code and all the applications involved in an Automation scheme must run locally on the user’s computer.
Perhaps the biggest challenge to developers using Automation is that the interface exposed by an
Automation server is invisible. You only know it’s there because VBA’s IntelliSense reveals various
methods to you. Even then, just knowing that the interface is there and knowing the names of the
interface objects supported by the Automation server isn’t necessarily enough. You need to know
something about how the Automation server works, so that you can use the methods appropriately.
Knowing which of the exposed objects to use for a particular task can be daunting. Word 2010, for
example, exposes more than 340 different objects in its Automation interface. Generally speaking,