WH_MOUSE について質問があります。私が読んだことから、フックをDLLに入れることで、プロセスが挿入されます。マウスのキャプチャがデスクトップやメニューの開始などでも機能するということですか? また、アプリケーションのタイトル バーについてはどうでしょうか。このような問題を抱えたインターネット上の投稿を見たことがありますが、それらが何かで失敗したのか、何らかの制限 (または別のアプローチ) があるのか わかりません。
WH_MOUSE と WH_MOUSE_LL の間のパフォーマンスについても質問があります。WM_MOUSE の方が WH_MOUSE_LL よりも速いという記事をどこかで見つけましたが、それは本当に目立ちますか? もしそうなら、どのような状況でシステムがそれほど遅くなる可能性があるのでしょうか? マウスとキーボードのクリックのみを記録したい場合、WH_MOUSE_LL は効率的でしょうか?
ありがとう！
どちらのフックも、画面上の任意の場所でマウス入力を取得します (以下にリストされている場合を除く)。これらは、この高レベルの機能の観点からは本質的に同じです。
どちらも UIPI の影響を受けます。マウスが昇格したプロセス上にある場合、どちらのフックもマウス入力を取得しません。
低レベルのフックは DLL を必要としないため、C# で使用できます。もう 1 つのタイプでは、アンマネージ コード (C/C++) で記述された別の DLL が必要です。
32 ビット プロセスと 64 ビット プロセスを混在させて実行できる 64 ビット マシンで実行している場合、低レベルのフックは両方のタイプのプロセスからイベントを受信しますが、他のタイプのフックはイベントのみを表示します。それ自体と同じ「ビット数」のプロセスから (この制限はフック DLL の使用に由来します。32 ビット フック DLL は 32 ビット プロセスにのみフックでき、64 ビットの場合も同様です)。この場合、LL フックでは 1 つのプロセスだけが必要ですが、他のタイプのフックでは、32 用と 64 用の 2 つの協調プロセスが必要です。
LL フックでは、メッセージ ループが実行されている必要があります。
LL フックは、コールバックが独自のプロセスで発生するため、記述が簡単であり、独自のグローバル変数などにアクセスできます。他のタイプのフックでは、コールバックが別のプロセスで発生するため、情報をメイン プロセスに戻すために追加の作業を行う必要があります。(どちらの場合も、コールバック内のコードを最小限に抑える必要があります。基本的なフィルタリングとチェックを行うだけで、コールバックではなくメインライン コードから重要な作業を行います。)
入力通知がプロセスにマーシャリングされ、そこで処理され、コンテキストが元のプロセスに再び切り替わるため、LL フックは「遅く」なります。他のタイプのフックでは、コンテキスト スイッチはありません。ただし、これはユーザーが気付く場合と気付かない場合があり、コールバックで何を行っているか、情報をどのように処理しているか、フックがインストールされている期間、およびその他の要因によって異なります。
タイトル バーの問題は、この質問で対処されているようです。要約すると、タイトルバー (およびその他の非クライアント領域) ではWM_NCMOUSEMOVEメッセージが表示され、他の場所では WM_MOUSEMOVE メッセージが表示されるため、両方を確認する必要があります。
私の 2c: 単純なユーティリティを作成したり、趣味でコーディングしたりする場合は、_LL を使用してください。それはかなり簡単で、よりトリッキーなケースのほとんどを処理します。64/32 ビットの問題やプロセス間の通信について心配する必要がないため、すぐに起動して実行できます。アプリ ロジックが機能するようになったら、必要に応じてコードを他のタイプのフックに変換できます。一方、「善良な市民」であり、他のアプリへの影響を最小限に抑える、より「プロフェッショナル」なアプリが必要な場合は、他のタイプのフックがより適切な場合があります。しかし、関連するすべてのパフォーマンスと同様に、最初に測定し、仮定しないでください。その場合でも、とにかく _LL フックから始めるのがおそらく最善です。