カスタム Windows コントロールでテキスト入力をサポートできるようにしたいのですが、EDIT およびリッチ エディット コントロールが既に行っているように、それらのいずれもサブクラス化しません。コントロールは現在、Direct2D と DirectWrite を使用してテキストを描画し、Platform Update 以降を適用した Windows Vista SP1 で動作します (より新しい Direct2D と DirectWrite 機能が必要であると判断した場合は、Platform Update を適用した Windows 7 SP1 以降に変更する可能性があります。そこまたは Windows 8 でのみ利用可能ですが、それは別の問題です...)
価値があるのは、OS XI ではNSTextInputClientを使用し、GTK+ ではGtkIMContextを使用することです。私が話しているのは、これらのようなことです。
当然の選択は を使用することWM_CHARです。正しく収集すると、ウィンドウ クラスが に登録されている場合はネイティブに UTF-16 になるRegisterClassW()ため、場所に関係なく「正常に動作する」はずです。ただし、WM_CHARは によって生成されTranslateMessage()、そのドキュメントには、常に非ゼロを返すため、 aWM_CHARが生成されたかどうかを判断する方法はないと書かれています。TranslateMessage()現在のキーボード メッセージがテキスト システムによって処理されるかどうか (したがって、無視する必要があるかどうか) を判断できる必要があります。テキスト以外のすべてのキーは、レイアウトに依存しない方法で処理する必要があるため、これは特に当てはまります (私は既に持っています)。
IMM API とテキスト サービス フレームワークの両方の Windows 7 サンプル コードも確認しました。どちらが優れているかはわかりませんが、どちらも同じことをしているようです。彼らは？
IMM の場合、WM_IMM_xxx無視すべきかどうかわからないメッセージが多数あり、Unicode ウィンドウでそれらを処理する必要があるかどうかについて、私が見つけたすべての参照が一致していないようです。 .. また、特定のキー イベントが IMM によって処理されるかどうかを知るという上記の問題は、まだ未解決です。方法はありますか？
TSF には ACP と呼ばれる概念があり、実際に使用するテキスト (つまり、進行中の構成ではない) を格納するために必要なテキスト格納形式を使用できるようです。これは本当ですか？テキストを属性付きの UTF-8 として保存し、描画時に (DirectWrite の場合) UTF-16 に変換できるようにしたいと考えています。他の API の選択肢でもこれを実行できますか?
または、私は完全に間違った道を進んでいますか？
そして、それをすべて行ったら、どのようにスクリーン キーボードをオプトイン し ますか?
私が使用した他の参考文献：
ありがとう。
2016 年 11 月 7 日更新
TsfPad のサンプルをもう一度見てみると、単にWM_CHAR;を使用しているように見えることに気付きました。今では、TSFをどのように使用しているのかさえわかりません.