我希望能够在自定义Windows控件中支持文本输入，就像EDIT和Rich Edit控件已经做到的那样，但不能将它们中的任何一个子类化。该控件当前使用Direct2D和DirectWrite绘制文本，并在带有Platform Update或更高版本的Windows Vista SP1上运行（如果我决定需要较新的Direct2D和DirectWrite功能，我可能会将其更改为带有Platform Update或更高版本的Windows 7 SP1。在那里或仅在Windows 8上可用，但这是一个不同的问题...）
就其价值而言，在OS X上我将使用NSTextInputClient，在GTK +上我将使用GtkIMContext。我正在谈论的就是这些东西。
显而易见的选择是使用WM_CHAR，如果我正确收集的话，如果在RegisterClassW()中注册了窗口类，则它本来就是UTF-16，因此无论在何处都应该“正常工作”。但是，WM_CHAR由TranslateMessage()生成，并且its documentation表示无法确定是否已生成WM_CHAR，因为TranslateMessage()始终返回非零。我需要能够确定当前的键盘消息是否将由文本系统处理（因此应忽略）；尤其是因为所有非文本键都需要以与布局无关的方式处理（我已经拥有）。
我还在Windows 7示例代码中看到了IMM API和Text Services Framework的代码。我不确定一个人是否比另一个人好，他们似乎都在做同一件事。有吗
对于IMM，有许多WM_IMM_xxx消息不确定我是否应该忽略，我发现的每个引用似乎都不同意我是否应该在Unicode窗口中处理它们。是否...此外，上述关于是否知道给定键事件是否将由IMM处理的问题仍然存在。有办法吗？
TSF有一个称为ACP的概念，它似乎允许我使用想要的任何文本存储格式来存储我实际要使用的文本（即不是正在进行的编写）。这是真的？我希望能够将文本存储为具有属性的UTF-8，在绘制时转换为UTF-16（用于DirectWrite）。其他API选择是否也允许我这样做？
还是我完全走错了道路？
一旦完成所有这些操作，我将如何opt into the on-screen keyboard？
我使用的其他参考资料：
http://www.catch22.net/tuts/unicode-text-editing
谢谢。
2016年11月7日更新在再次查看TsfPad示例后，我注意到它似乎也只使用WM_CHAR；现在我不确定它如何使用TSF，除了它可以使用...
最佳答案
TSF API是IMM API的超集。它也比IMM更新，是处理国际文本输入（以及其他输入机制（如手写和语音））的当前，现代方法。
如果使用TSF API，则通过API而不是Windows消息显示文本（因此，与哪个消息无关）。
屏幕键盘是自动处理的，您不必担心。 （TSF的全部目的是使您的应用独立于输入源。）
TSF可以支持UTF-8，但是有点麻烦。您需要将扩展字符标记为隐藏。使用UTF-16（TSF的默认API）会更好。
关于如何将TSF支持添加到现有编辑控件中，我所知道的最好的例子仍然是我在July 2007中写的文章。
输入仍然可以通过WM_CHAR到达（例如，如果当前输入配置文件是键盘布局），那么您也需要实现它;不过，通常情况下，您可以通过调用ITextStoreACP::InsertTextAtSelection实现来处理WM_CHAR消息。