在Windows上的自定义控件中处理任意文本输入的正确，现代的方法是什么? WM_CHAR? IMM? TSF? [英] What is the correct, modern way to handle arbitrary text input in a custom control on Windows? WM_CHAR? IMM? TSF?
问题描述
我希望能够在自定义Windows控件中支持文本输入，就像EDIT和Rich Edit控件已经做到的那样，但不能将它们中的任何一个子类化.该控件当前使用Direct2D和DirectWrite绘制文本，并在带有Platform Update或更高版本的Windows Vista SP1上运行(如果我决定我需要较新的Direct2D和DirectWrite功能，我可能会将其更改为带有Platform Update或更高版本的Windows 7 SP1.在那里或仅在Windows 8上可用，但这是一个不同的问题...)
I want to be able to support text input in a custom Windows control, just like the EDIT and rich edit controls already do, but not subclassing either of those. The control currently uses Direct2D and DirectWrite to draw text, and runs on Windows Vista SP1 with Platform Update or newer (I might change it to Windows 7 SP1 with Platform Update or newer if I decide I need newer Direct2D and DirectWrite features, assuming those are available there or on Windows 8 only, but that's a different question...)
对于它的价值，在OS XI上将使用 NSTextInputClient 在GTK +上，我将使用 GtkIMContext .我正在谈论的就是这些东西.
For what it's worth, on OS X I would use NSTextInputClient and on GTK+ I would use GtkIMContext. It's things like these that I'm talking about.
显而易见的选择是使用WM_CHAR，如果我正确收集的话，如果在RegisterClassW()中注册了窗口类，则它本机为UTF-16，因此无论位置在哪里都应该正常工作".但是，WM_CHAR由TranslateMessage()生成，并且其文档表示无法确定是否已生成WM_CHAR，因为TranslateMessage()始终返回非零.我需要能够确定当前的键盘消息是否将由文本系统处理(因此应忽略)；尤其如此，因为所有非文本键都需要以与布局无关的方式(我已经拥有)进行处理.
The obvious choice is to use WM_CHAR, which if I gather correctly, is natively UTF-16 if the window class is registered with RegisterClassW(), and therefore should "just work" regardless of location. However, WM_CHAR is generated by TranslateMessage(), and its documentation says there is no way to determine whether a WM_CHAR has been generated or not, since TranslateMessage() always returns nonzero. I need to be able to determine whether the current keyboard message will be handled by the text system (and thus should be ignored); this is especially true since all non-text keys need to be handled in a layout-independent way (which I already have).
我还在Windows 7示例代码中看到了IMM API和Text Services Framework的代码.我不确定一个人是否比另一个人好，他们似乎都在做同样的事情.他们吗?
I've also seen in the Windows 7 samples code for both the IMM API and the Text Services Framework. I'm not sure whether one is better than the other, and they both seem to do the same thing. Do they?
对于IMM，有许多WM_IMM_xxx消息不确定我是否应该忽略，我发现的每个引用似乎都不同意我是否应该处理它们.是否存在一个Unicode窗口...此外，上述关于是否知道给定键事件是否将由IMM处理的问题仍然存在；有办法吗?
In the case of IMM, there are a number of WM_IMM_xxx messages that I'm not sure if I should be ignoring or not, and every reference I've found seems to disagree as to whether I should handle them in a Unicode window or not... Also, the above problem of knowing if a given key event will be handled by IMM or not is still open; is there a way?
TSF有一个称为ACP的概念，它似乎允许我使用想要的任何文本存储格式来存储我实际要使用的文本(即不是正在进行的编写).这是真的?我希望能够将文本存储为具有属性的UTF-8，在绘制时转换为UTF-16(用于DirectWrite).其他API选择是否也允许我这样做?
TSF has a concept called ACP, which seems to allow me to use whatever text storage format I want for storing the text I'm actually going to use (that is, not an in-progress composition). Is this true? I'd like to be able to store my text as UTF-8 with attributes, converting to UTF-16 when drawing (for DirectWrite). Do the other API choices also let me do this?
还是我完全走错了路?
以及我将如何 opt 插入 屏幕键盘一旦我完成所有这些操作?
And how would I opt into the on-screen keyboard once I do all of that?
我使用的其他参考文献:
Other references I used:
谢谢.
更新 2016年11月7日
再次查看了TsfPad示例后，我注意到它似乎也只使用了WM_CHAR；现在我不确定它如何使用TSF，除了它可以使用...
UPDATE 7 Nov 2016
After looking at the TsfPad sample again, I notice it also seems to just use WM_CHAR; now I'm not sure how it even uses TSF, other than that it does...
推荐答案
TSF API是IMM API的超集.它也比IMM更新，是处理国际文本输入(以及手写和语音等其他输入机制)的当前，现代方法.
The TSF API is a superset of the IMM API. It's also newer than IMM, and is the current, modern way to handle international text input (as well as other input mechanisms like handwriting and speech).
如果使用TSF API，则通过API而不是Windows消息显示文本(因此，与哪个消息无关).
If you use the TSF API, text appears via the API instead of windows messages (so the issue of which message is irrelevant).
屏幕键盘是自动处理的，您不必担心. (TSF的全部目的是使您的应用独立于输入源.)
The On-Screen keyboard is handled automatically, and you shouldn't have to worry about it. (The entire purpose of TSF is to make your app independent of input source.)
TSF 可以支持UTF-8，但这有点麻烦.您需要将扩展名标记为隐藏.使用UTF-16(TSF的默认API)会更好.
TSF can support UTF-8, but it's a bit of a pain; you need to mark the extension characters as hidden. You would be much better off with UTF-16, which is TSF's default API.
我所知道的关于如何向现有编辑控件添加TSF支持的最佳示例仍然是我在
The best example I know of on how to add TSF support to an existing edit control is still the article I wrote back in July 2007.
输入可以仍然可以通过WM_CHAR到达(例如，如果当前输入配置文件是键盘布局)，那么您也需要实现它；不过通常情况下，您可以通过调用 ITextStoreACP :: InsertTextAtSelection 实现.
Input can still arrive via WM_CHAR (if the current input profile is a keyboard layout, for example), so you need to implement this as well; typically, though, you can handle WM_CHAR messages by calling into your ITextStoreACP::InsertTextAtSelection implementation.
这篇关于在Windows上的自定义控件中处理任意文本输入的正确，现代的方法是什么? WM_CHAR? IMM? TSF?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
