問題タブ [text-services-framework]

Get the Candicate List by TSFの記事 (日本語ですみません) を参考に、Windows Store Appの C++ Component を開発しました。
しかし、コンポーネントをテストすると、奇妙な現象が発生します。インプット メソッドを「Microsoft IME」にすると、コードが

出力パラメータ「range_cp」では常に NULL を返しますが、入力メソッドを「Google 日本語入力」にすると、「range_cp」は正しい結果を返し、ITfFnReconversion::GetReconversion によって候補リストを取得できます。
誰かが同じ問題に遭遇しましたか? または、Microsoft IME の一部の設定が抜けていませんか?

この問題のコードの一部があります。

あなたが提供できる助けに本当に感謝します。

カスタム 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 の選択肢でもこれを実行できますか?

または、私は完全に間違った道を進んでいますか？

そして、それをすべて行ったら、どのようにスクリーン キーボードをオプトイン し ますか?

私が使用した他の参考文献：

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

ありがとう。

2016 年 11 月 7 日更新
TsfPad のサンプルをもう一度見てみると、単にWM_CHAR;を使用しているように見えることに気付きました。今では、TSFをどのように使用しているのかさえわかりません.

これは、 Windows のカスタム コントロールで任意のテキスト入力を処理する正しい最新の方法は何ですか?からの続きです。WM_CHAR? IMM? TSF? .

したがって、非 IME レイアウト (米国英語)、非 TSF IME (Windows XP DDK の日本語 FAKEIME)、および TSF テキスト サービス (Windows 7 に付属するもの) を試してみたところ、アクティブな入力プロセッサ プロファイルは TSF テキスト サービスではありません (つまりTF_PROFILETYPE_KEYBOARDLAYOUT、WM_CHAR.

私の問題は、現在のキー メッセージがテキスト入力メッセージに変換されたため、無視できることをアーキテクチャに伝える方法が必要なことです。これが翻訳の前後に発生するかどうかは気にしません。そのような翻訳が行われるか、または行われたことを知る必要があるだけです。または疑似コードの用語で：

キーボードまたは非 TSF IME からのテキスト入力を処理する標準的な方法は、 -to- translation を実行させるTranslateMessage()ことです。ただし、問題があります。MSDN によるとWM_KEYDOWNWM_CHAR

メッセージが WM_KEYDOWN、WM_KEYUP、WM_SYSKEYDOWN、または WM_SYSKEYUP の場合、変換に関係なく、戻り値はゼロ以外です。

つまり、翻訳が行われたかどうかを判断するために使用することはできません。

Michael Kaplan のブログ投稿をいくつか読んだ後、ToUnicode()orToUnicodeEx()を使用して自分で変換を行い、状態配列 from を渡すことができると考えましたGetKeyboardState()。ワインのソース コードは一致しているように見えますが、2 つの特別なケースがあり、それらがワイン固有のものなのか、実際の Windows でも実行する必要があるのか​​はわかりません。

• VK_PACKET—WM_CHARメッセージのLPARAM
• VK_PROCESS—ImmTranslateMessage()ワイン固有の関数または文書化されていない imm32.dll 関数のように見える function を呼び出します。どれが本当か分からない

WM_KEYUPそしてワインもandでは何もしませんWM_SYSKEYUP。繰り返しますが、これがワインのみに当てはまるかどうかはわかりません。

しかし、TSF を使用するプログラムでこれらのケースについて心配する必要さえあるのでしょうか? もしそうなら、そうするための「公式の」方法は何ですか？WM_KEYUPそれでも、私は/で何をしますかWM_SYSKEYUP; それらも送信する必要がありToUnicode()ますか？WM_KEYUPがあった場合、特別にウィンドウで sをキャッチする必要がありWM_CHARますか?

または、MSDN TSF サンプルのいずれにも含まれていない、TSF にTF_PROFILETYPE_KEYBOARDLAYOUTプロセッサを処理させるだけの何かが欠けているのでしょうか? TSF は透過的な IME パススルーを行うと思っていましたが、FAKEIME サンプルを使った実験ではそうではないことがわかりました...? Firefox と Chromium の両方が、キーボード レイアウトが IME によってサポートされているかどうかを確認し、確認するためTF_PROFILETYPE_KEYBOARDLAYOUTに使用していることもわかりますが、これらの場合に実際に入力自体を処理するかどうかはわかりません...ImmGetIMEFileName()

現在の最小バージョンは Windows 7 です。

ありがとう。

更新この質問の元のバージョンには、関連するWM_KEYUPs について知る必要が含まれていました。他のプラットフォームで同等のコードをもう一度見てみると、これは結局のところ必要ありませんTranslateMessage()。それに応じて質問を調整しました。(OS X では、キー リリース イベントをテキスト入力システムに渡すことさえしません。GTK+ では行いますが、文字を挿入するキー押下はリリースを気にしないようで、とにかく処理されません。少なくとも私が試した入力方法 (いくつかあるかもしれません...)。そうは言っても、何かを見逃した場合は、別のサブ質問を追加しました。