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

Question

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

对于它的值(value)，在 OS X 上我会使用 NSTextInputClient在 GTK+ 上我会使用 GtkIMContext .我正在谈论的就是这些。

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

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

在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 的，除此之外...

Answer 1

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 消息。执行。