Automating Other Office Applications

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

This section covers the basic steps required to prepare for automating an Office application from another application. This is often referred to as running code from a host application to automate another application. Although automating one Office application from another is generally accomplished in the same way, there are some important differences regarding how you work with each application; those differences are discussed in this section.

Note When VBA code references an object that is not installed, the Windows installer technology will attempt to install the required feature. In all Office applications except Outlook and FrontPage, you can use the FeatureInstall property to control what happens when an uninstalled object is referenced. When this property is set to the default (msoFeatureInstallOnDemand), any attempt to use an uninstalled object causes the Windows installer to try to install the requested feature. In some circumstances, this may take some time, and the user may believe that the machine has stopped responding to additional commands. To address this, you can set the FeatureInstall property to msoFeatureInstallOnDemandWithUI to display a progress meter so that users can see that something is happening as the feature is being installed. If you want to trap the error that is returned and display your own dialog box to the user or take some other custom action, you can set the FeatureInstall property to msoFeatureInstallNone. For more information and details about application-specific behavior, see Chapter 2, "Designing and Deploying Office Solutions," or search the Office application's Help index for "FeatureInstall property."