Events Overview

Taken in the most general sense, the concept of automation is that of two objects communicating with each other. These objects may be two applications, or an application and a COM component. Ultimately, however, it comes down to two COM components, although that is not really the point. The point is two items are exchanging information between them.

In the case of SAPI, it is easy to get the impression that the Visual Basic application makes all the calls to SAPI and receives nothing in return. You can get that impression because most of the emphasis of this documentation suite features the several hundred available calls to SAPI. But in fact, there is a two-way communication going on. The feedback from SAPI and the speech engines plays a critical role in a speech application.

SAPI interacts with the host application using events. An event is a signal sent to the application by an outside source. The event indicates that some condition exists outside of the application that may be of interest to the user. The outside source in this case is SAPI and examples of events may indicate that a recognition is available or that the SAPI engine is ready to accept input.

Events are not limited or unique to SAPI. They are the standard method to get information back to the host application. It is common for other applications to send events. An example of an event sent back to an application is that of an e-mail application running in the background notifying users whenever a new e-mail arrives. Unlike a conventional method or property, which must be explicitly coded by the programmer and called at a specific time, events may be sent or received at any time. It is even possible for events to be sent faster than the host application can process. Yet this rarely is disruptive to the user or the current application.

Far from interfering with the application, events intend to enhance the user experience. For example, moving the pointer over menu items alters the appearance of individual buttons and indicates that the menu item is available. This type of event is handled transparently to users, and they do not need to respond in any way. It is even transparent to programmers because the change in appearance is automatic and requires no code implementation. Nevertheless, the application is responding to an event.

Events can be considered to be of one of two types: user-initiated or background generated. As the name implies, a user-initiated event is one initiated by the user. A common instance is that of the user clicking a command button. This actually generates several events including a MouseDown event and Click event. A graphical user interface (GUI, pronounced gooey) is an example of many user-initiated events; that is, the user starts various activities such as clicking a menu, opening an application, or entering text. Conventional GUI programming relies extensively on an event loop. This endless loop waits for events. After receiving one, the event is dispatched and whatever action it is intended to do begins. Visual Basic applications have an event loop, although it is hidden from the programmer.

Background generated events, on the other hand, are events initiated not by the user but by some other source such as another application (such as SAPI) or the operating system. This is how applications inform one another about something of interest. For instance, if an application were using automation with Microsoft Word, it is possible for Word to send an event whenever a file is deleted, printed, or opened. The application could respond or even ignore the event if it were unimportant. SAPI sends back events in the same way. For example, when SAPI finishes processing a phrase and has a recognition ready, it sends a recognition event to the host application. Handling an event is similar to a function or subroutine except an event is invoked automatically.