TSF Application interfaces
The first stop on the TSF tour is the application interfaces. These are implemented by applications or text controls.
An application (or text control) must implement ITextStoreACP to be considered ‘TSF-aware'. It may choose to implement any of the other interfaces described in the table below. I also describe how TSF obtains an instance of each interface.
Interface |
Optional? |
How Obtained? |
|---|---|---|
No |
Passed to ITfDocumentMgr::CreateContext |
|
Yes |
Returned from ITextStoreACP::RequestSupportedAttrs with GUID_PROP_INPUTSCOPE. |
|
Yes |
QI from ITfInputScope |
|
Yes |
Passed to ITextStoreACPServices::Unserialize |
|
Yes |
QI from ITextStoreACP |
|
Yes |
Passed to ITfDocumentMgr::CreateContext |
|
Yes |
Passed to ITfSource::AdviseSink (see below) |
Note: I put ITfUIElementSink here because text services never implement this interface, even though it's an event sink (described in a future post). Full-screen applications (or games) would implement this interface if they wish to control the UI drawn by text services. (See the discussion of UILess mode in MSDN.)
Interface |
When to implement |
|---|---|
Always implement this. |
|
Consider implementing this. It's not hard, and some text services use it to improve recognition (e.g., Windows Speech Recognition knows about the URL input scope, and has special code for that). |
|
Implement this if you implemented ITfInputScope, and you need the extra functionality (string enumeration). |
|
Implement this if you support asynchronous property loading. If you don't know what that means, you don't need to implement this. |
|
Implement this to help handwriting recognition (I believe that you must implement this to get gestures). |
|
Implement this if you need control over compositions. |
|
Only implement this if your application takes over the screen, and you still want IMEs to work inside your application. It's a fair amount of work to implement this. |