ISpEventSource::SetInterest
ISpEventSource::SetInterest sets the type of events the client is interested in.
Sets the type of events which will invoke a notification and become queued.
HRESULT SetInterest(
ULONGLONG ullEventInterest,
ULONGLONG ullQueuedInterest
);
Parameters
- ullEventInterest
- [in] Event ID flags indicating which events should invoke a notification to the event sink that this event source uses. Must be of type SPEVENTENUM.
- ullQueuedInterest
- [in] Event ID flags indicating which events should be queued. The event flags set here must also be set in dwEventInterest. Must be of type SPEVENTENUM.
Return values
Value | Description |
---|---|
S_OK | Function completed successfully. |
E_INVALIDARG | Invalid flags passed in one or more fields. |
FAILED(hr) | Appropriate error message. |
Remarks
If SetInterest is never called, the SR engine defaults to SPEI_RECOGNITION as the only event and queued interest. A TTS engine defaults to zero for both event and queued interest. With either engine, no events will be passed through if both parameters are set to zero.
Note that the SPFEI() macro will be used to convert an event enumeration into the appropriate flags to pass to this method. For example, to receive the SPEI_RECOGNITION and SPEI_HYPOTHESIS events, call this function as follows:
// Declare local identifiers:
HRESULT hr = S_OK;
CComPtr<ISpEventSource> cpEventSource;
ULONGLONG ullMyEvents = SPFEI(SPEI_RECOGNITION) | SPFEI(SPEI_HYPOTHESIS);
// Set type of events the client is interested in.
hr = cpEventSource->SetInterest(ullMyEvents, ullMyEvents);
if (SUCCEEDED(hr))
{
// Do stuff here.
}
Events specified in ullEventInterest must be a superset of those specified in the ullQueuedInterest. Therefore it is possible to have notifications of events but not actually queue them. This can be useful for polling the GetStatus method, especially for TTS.