5

我希望能够支持自定义 Windows 控件中的文本输入,就像 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()它的文档说没有办法确定 aWM_CHAR是否已经生成,因为TranslateMessage()总是返回非零。我需要能够确定当前的键盘消息是否将由文本系统处理(因此应该被忽略);尤其如此,因为所有非文本键都需要以独立于布局的方式(我已经拥有)进行处理。

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

在 IMM 的情况下,有许多WM_IMM_xxx消息我不确定是否应该忽略,而且我发现的每个参考似乎都不同意我是否应该在 Unicode 窗口中处理它们。 .. 此外,上述知道给定关键事件是否将由 IMM 处理的问题仍然存在;有办法吗?

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

还是我完全走错了路?

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

我使用的其他参考资料:

谢谢。

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

4

1 回答 1

1

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

如果您使用 TSF API,文本会通过 API 而不是 windows 消息显示(因此哪个消息的问题无关紧要)。

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

TSF可以支持 UTF-8,但是有点痛苦;您需要将扩展​​字符标记为隐藏。使用 UTF-16 会更好,这是 TSF 的默认 API。

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

输入仍然可以通过 WM_CHAR 到达(例如,如果当前输入配置文件是键盘布局),因此您也需要实现这一点;但是,通常,您可以通过调用ITextStoreACP::InsertTextAtSelection实现来处理 WM_CHAR 消息。

于 2016-11-07T22:50:31.143 回答