ISpNotifySink
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
This interface specifies an event sink to receive notifications. In both speech synthesis and speech recognition, applications receive notifications when words have been spoken or when phrases have been recognized. SAPI components that generate notifications implement ISpNotifySource.
The ISpNotifySink and ISpNotifySource interfaces alone only provide a mechanism for a notification but no information on the events that caused the notification. With an ISpEventSource object, an application can retrieve information about the events that caused the notification. ISpEventSource also provides the mechanism to filter and queue events. By default, an application (really an ISpNotifySink) receives no notifications from ISpEventSource until SetInterests has been called to specify on which events to notify or queue.
When an application is notified of an event that is not queued, an application will take measures based on which event sink is receiving the notification. From context an application may know exactly what it needs to do, or it may need to interact with the components that sent the notifications. If an application is notified of an event that is queued, then the application will call ISpEventSource::GetEvents to retrieve the actual events that caused a notification.
When to Implement
Implement this interface only if the application can take advantage of the slightly reduced latency of a free-threaded notification. Most applications should use one of the simplified notification mechanisms in ISpEventSource instead of implementing this interface directly. Free-threaded notifications are difficult to implement without deadlocking the system. Furthermore, other notification mechanisms require less code on the part of the developer. The application needs to handle free-threaded notifications then implement the ISpNotifySink interface when an ISpNotifySink object is to be notified.
Because free-threaded notifications can occur on any thread, at any point during execution, they are extremely prone to deadlocks and reentrancy problems. The only interface that can be called on an event source object is ISpEventSource::GetEvents. If ISpNotifySink is implemented directly, the code should only use some mechanism to signal another thread to process the notification (for example, a Win32 event or an I/O completion port), and, if needed, call ISpEventSource::GetEvents. Do not call any other methods.
Methods
The following table lists the methods for the ISpNotifySink interface.
| Method | Description |
|---|---|
Called by an ISpNotifySource object to notify the sink when the state of the notify source has changed. |
Requirements
| Header | sapi.h, sapi.idl |
| Library | sapilib.lib |
| Windows Embedded CE | Windows CE .NET 4.1 and later |