Automation Overview (SAPI 5.4)
Automation is the ability of one entity (or object) to communicate with another object. These entities may be applications or ActiveX® controls, although ultimately they all use COM (component object model) as the common denominator. The underling complexity is removed for the Visual Basic programmer. The result is that your application can access features and information from other sources. This interaction can be as involved as sharing information between the two applications, such as between your Visual Basic application exporting or importing data form a database or spreadsheet. Automation also allows you to issue basic commands such as Open and Print. This way, developers can integrate their favorite spreadsheet or word processor capabilities with methods unique to a particular corporate environment. For example, while you could write your own spell checker for your Visual Basic application, your application could access the Microsoft Word spell checker, thus saving time and effort. In Visual Basic, this scenario using standard applications is commonly referred to as Visual Basic for Applications (VBA). VBA is a specialized subset of Visual Basic and is designed to manage applications for custom solutions.
A second use of automation includes components. A component can be considered an additional functionality provided outside of the capabilities of any programming language itself. For example, Visual Basic provides a basic text box for displaying text and although that text may be italic or bold, all the text must share the same characteristics. For example, it must all be bold, or all the same font size. On the other hand, a rich text edit box may be added to the Visual Basic Toolbox. Using this rich text edit box, you can change the font, size and appearance of the text. However, this capability must be explicitly added using the appropriate component on the Components menu. In reality, that rich text edit box is a COM object. Because COM is intended to offer programmers flexibility, there is a robust set of components available. Many come with the Visual Basic package, others are available through third party sources, and some are designed for specific purposes such as in-house corporate environments. This ability to compartmentalize features and functionality gives components their popularity.
A third use of automation is its ability to access dynamic link libraries (or DLLs). This aspect of automation involves applications without a user interface. SAPI, for instance, has no interface per se. While users can incorporate SAPI functions into their own applications, they cannot run SAPI in a conventional sense and have a user interface, as well as menus and documents. Developers however, have access to all of SAPI's functions in a programmatic way using dynamic link libraries (DLLs). If DLLs exist on the computer, a developer can access them by linking their development environment to them. In the case of Visual Basic, SAPI may be added using the Microsoft Speech Object Library on the References menu. If a particular DLL is not present, it can be installed using the manufacturer's installer. For example, sapi.dll is loaded when developers install SAPI.
DLLs are used frequently. A search for *.dll reveals the true extent of their use. Using them, developers can introduce new components or capabilities to an operating system without compiling them into the system. DLLs may be, and usually are, loaded after the operating system. However, their mere presence does not affect any application. As mentioned, developers need to make calls to DLLs before a DLL can have an effect on an operating system. Since SAPI has no interface, this document is the only guide to accessing its features. The application programming interface (API) acts as a guide and provides a list of all the possible calls, explanations of them, and guidelines for successfully using them. Certain calls must be made in a specific order to keep SAPI automation simple. This API explains these issues and eases development concerns. Also available with this documentation is the software development kit (SDK), which provides supplementary information such as code examples and additional tools. Developers are encouraged to review the sample code and possibly base their applications on it.
Even though three different uses of automation are described above, ultimately all automation uses an identical foundation. Automation itself is a complex technology. It has evolved over the years and, no doubt, will continue to evolve to accommodate changing technologies and the increasing sophistication demanded by the marketplace. Older programmers will remember OLE (object linking and embedding), which evolved into ActiveX, COM, and COM+. All of these programs are progressions of what is commonly called automation. Fortunately automation's complexity is hidden. Support is usually built into the operating system now and accessing these technologies, or individual aspects of them, is nothing more than making a selection from a list within the development environment.
The concept of automation using COM is that of programming language independence. As long as the object complies with COM standards, any programming language may be used. This documentation suite addresses the SAPI automation programming using Visual Basic; however, Visual Basic is not actually required. In fact, many of the same calls and calling syntax may be used in other computer languages, provided they support automation. This includes the ability to use JScript®, Visual C#®, or possibly other solutions that support automation. Visual Basic is used here because of its popular and widespread support in marketplace. Also, it has supported automation virtually since its inception and the Visual Basic tool suite offers a variety of options.