在 Windows 上的自定义控件中处理任意文本输入的正确、现代方法是什么？WM_CHAR？注塑机？TSF？

Question

我希望能够支持自定义 Windows 控件中的文本输入，就像 EDIT 和 Rich Edit 控件已经做的那样，但不对其中任何一个控件进行子类化。该控件当前使用 Direct2D 和 DirectWrite 绘制文本，并在带有平台更新的 Windows Vista SP1 或更高版本上运行（如果我决定需要更新的 Direct2D 和 DirectWrite 功能，我可能会将其更改为带有平台更新的 Windows 7 SP1 或更高版本，假设这些功能是在那里可用或仅在 Windows 8 上可用，但这是一个不同的问题......）

就其价值而言，在 OS XI 上我会使用NSTextInputClient，在 GTK+ 上我会使用GtkIMContext。我正在谈论的就是这样的事情。

显而易见的选择是使用WM_CHAR，如果我正确收集的话，如果窗口类是用 注册的RegisterClassW()，那么它本身就是 UTF-16 ，因此无论位置如何都应该“正常工作”。然而，WM_CHAR是由 生成的TranslateMessage()，并且它的文档说没有办法确定 a 是否WM_CHAR已生成，因为TranslateMessage()总是返回非零。我需要能够确定当前的键盘消息是否将由文本系统处理（因此应该被忽略）；这尤其正确，因为所有非文本键都需要以独立于布局的方式处理（我已经有了）。

我还在 Windows 7 示例代码中看到了 IMM API 和文本服务框架。我不确定一个是否比另一个更好，而且他们似乎都做同样的事情。他们吗？

就 IMM 而言，有许多WM_IMM_xxx消息我不确定是否应该忽略，并且我发现的每个参考文献似乎都不同意我是否应该在 Unicode 窗口中处理它们。 ..此外，上述了解 IMM 是否会处理给定按键事件的问题仍然悬而未决；有办法吗？

TSF 有一个称为 ACP 的概念，它似乎允许我使用我想要的任何文本存储格式来存储我实际要使用的文本（即，不是正在进行的合成）。这是真的？我希望能够将文本存储为带有属性的 UTF-8，在绘图时转换为 UTF-16（对于 DirectWrite）。其他 API 选项也可以让我这样做吗？

或者我完全走错了路？

完成所有这些操作后，我将如何选择 使用 屏幕键盘？

我使用的其他参考资料：

• http://www.catch22.net/tuts/unicode-text-editing

谢谢。

2016 年 11 月 7 日更新
再次查看 TsfPad 示例后，我注意到它似乎也只是使用WM_CHAR; 现在我不确定它是如何使用 TSF 的，除此之外......

Answer 1

TSF API 是 IMM API 的超集。它也比 IMM 更新，是当前处理国际文本输入（以及其他输入机制，如手写和语音）的现代方式。

\n\n

如果您使用 TSF API，则通过 API 显示文本而不是 Windows 消息（因此哪条消息的问题无关紧要）。

\n\n

屏幕键盘是自动处理的，您不必担心。（TSF 的全部目的是使您的应用程序独立于输入源。）

\n\n

TSF可以支持UTF-8，但是有点蛋疼；您需要将扩展​​字符标记为隐藏。使用 UTF-16 会更好，它是 TSF 的默认 API。

\n\n

我所知道的有关如何向现有编辑控件添加 TSF 支持的最佳示例仍然是我在2007 年 7 月写的文章。

\n\n

输入仍然可以通过 WM_CHAR 到达（例如，如果\xc2\xa0当前输入配置文件是键盘布局），因此您\xc2\xa0也需要实现这一点；不过，通常情况下，您可以通过调用ITextStoreACP::InsertTextAtSelection实现来处理 WM_CHAR 消息\xc2\xa0。

\n