問題タブ [getmessage]

WH_GETMESSAGEをAutoItにフックして、デスクトップ上のすべてのシステム/アプリウィンドウメッセージを検索し、ウィンドウが移動した場合に何かを実行する方法と、メッセージを送信したウィンドウからハンドルを保存する方法の例を誰かに教えてもらえますか？

外部プロセスでWM_CHARのGetMessage()呼び出しをインターセプトする方法を探しています (具体的には、アクティブなウィンドウのみ)。私はSetWindowsHookEx()を使用するのをためらっています- キーボード入力を変更する可能性のある可能な限り幅広いプログラムが最初に起動する可能性があることを絶対に確認したい. 誰か提案はありますか？

環境：現在のキーボード レイアウトのビジュアルを生成するためのアプリケーションを構築しています。ただし、サードパーティのキーボード再マッピング ソフトウェア (ユーザーが作成した AutoHotkey スクリプトなどを含む) と可能な限り互換性を持たせることを目指しています。ホットキーを介してトリガーされると、私のプログラムはアクティブなウィンドウ (スキャンコード + 適切な仮想キー) にキー押下を送信します。これは、ウィンドウ プロシージャによって処理される必要があります。したがって、システム全体のフックに基づくリマップ ソフトウェアと、アクティブなアプリケーション内のキーのみを再マップするようにプログラムされています...そして、私のプログラムは結果の WM_CHAR / WM_UNICHAR / WM_DEADCHAR メッセージを傍受し、そこからキーボードレイアウトを再構築します. 実際には、文字メッセージが出力用のアクティブ ウィンドウに到達することはありません。

PS申し訳ありませんが、登録後に最初に質問を投稿するのはおそらくマナー違反ですが、私はこの問題を何晩も調査してきましたが、まだ最適な解決策を見つけていません! 私は主に AutoHotkey で作業しており、真の現在のキーボード レイアウトを取得するために検討した他の方法を喜んで共有しますが、それらにはすべて制限があります。

.NETとWinAPIの周りにレイヤーを作成しています。関数を呼び出すなど、ユーザーがメイン関数に入る前にいくつかの準備をする必要がありGetMessageます。

別のスレッドでカスタムメイン関数を呼び出すdllからプログラムを開始することは可能ですか？

別のスレッドで実行する方が簡単ですが、主な脅威を呼び出すとGetMessageすぐに、まったく呼び出していないかのように、マウスが1分近く非常に遅くなります。しかし、Visual Studioでデバッグすると、が入力されるので、問題になることはありません。SetWindowsHookExWH_MOUSE_LLGetMessageGetMessage

誰かが助けてくれることを願っています。

アップデート

これが私が達成しようとしていることです。

user_source（cpp）

MyDLL（cpp）

それが問題です。スレッドを使用して関数を呼び出しましたが、メイン制御に戻ると、しばらくするとメインがスリープ状態になります。

例 (Lookこれは Win32API 関数を呼び出す行ですGetMessage):

このコードはeのステータスを 1000 回出力する必要がありますが、1 回しか出力されません。合理的なエラーが見つかりません。Lookメッセージを受け取るまで戻らないので、これがエラーの原因になっているのではないかと思います。

このスレッドによると: CreateWindow/CreateDialog からの HWND を別のスレッドから GetMessage することはできますか? 、メインスレッドのHWNDを使って別スレッドでGetMessageが使えないようです。

新しいスレッドから呼び出される GetMessage を使用して、編集テキスト内の値を取得しようとしているだけです。これを行うにはどのような方法がありますか?

私は同様のタイプのものを実装しています-以下のコードのelse部分にいくつかのメッセージボックスがあります..デバッグで得られるのは、同じメッセージボックスが何度も何度もあり、それが終了しないことです(これにより、プログラムが作成されます)クラッシュし、ラップトップを再起動する必要があります..解決策はありますか? MFC アプリケーションを使用して、ウィンドウ エクスプローラーのプレビュー ペインにボタンを作成しています。すべて問題ありませんが、これは、下のループに入ると抜け出せないという問題です (つまり、DispatchMessage または TranslateMessage に、この関数を何度も呼び出す何かがあるということです)..できませんでしたそれは何を見つけますか??

コードは次のとおりです-

リソース エディターを使用してボタン アプリケーションを作成しています。ボタンを作成した後、私はこのようにしようとしています -

別の場所で、このように createdialog 関数を定義します。

発生している問題は、デビュー時にコントロールが最初に CreateDialogParam に移動し、次に getmessage に移動して、コントロールがループから抜け出せず、再起動の問題が発生することです。また、プレビュー ペインにボタンと画像が表示されません。すべてがうまくいけば、デバッグ後にプレビューペインに画像が表示され、「次へ」と「前へ」の2つのボタンがありますが、空白のウィンドウしか表示されません（リソースエディターを使用して既に作成したボタンと写真.. . それは正しいと確信しています) .. しかし、getmessage 関数が出てこないのに、dispatchmessage が呼び出されない理由がわかりません (デバッグで見たからです)。

SetWindowsHookExを使用して WH_GETMESSAGE、WH_CALLWNDPROC、および WH_CALLWNDPROCRET をフックするグローバル フックを作成しました。
フック dll は、フックされたプロセスに新しいスレッドを作成します。このスレッドは、とりわけ、プロセスのオーディオ状態をチェックし、IAudioSessionManager2::GetSessionEnumerator()を呼び出します。

ここで興味深いのは、フック ホストからUnhookWindowsHookEx()を呼び出していて、dll のワーカー スレッドがIAudioSessionManager2::GetSessionEnumerator()への呼び出しを実行している間に呼び出していたことです。その呼び出しは、 DLL_PROCESS_DETACH を持つ DllMainが呼び出された同じスレッドの呼び出しスタックにありました。その理由は、GetSessionEnumerator()がどこかでGetMessage()関数を呼び出し、後者が再入可能であるためだと思います。残念ながら正確には覚えていませんが、コール スタックで確認したと思います。

しかし、私が疑問に思っている重要なことや不明な点が複数あります。だからここに私の関連する質問があります：

1. DLL_PROCESS_DETACH を指定した DllMain は、現在アンロードされている dll から関数を実行するスレッドであっても、いつでも呼び出すことができますか?
2. DllMain DLL_PROCESS_DETACH が終了すると、関数のスタックはどうなりますか? 呼び出しスタックの上の関数のコードは最終的に実行されますか?
3. これらの関数が終了しない場合はどうなりますか? dll はいつアンロードされますか?
4. DllMain DLL_PROCESS_DETACH は、WH_GETMESSAGE、WH_CALLWNDPROC、および WH_CALLWNDPROCRET フックのコールバック中に同様に呼び出すことができますか? あまり頻繁ではありませんが、これらの関数は再入可能であるため、前の呼び出しがまだ同じスタックで実行されている間にこれらの関数への呼び出しを挿入できることを知っており、実験的に確認しましたが、次の呼び出しも行うかどうかはわかりませんDllMain も同様の方法で注入できます。
5. 正確に DllMain をスレッドで呼び出すことができる場合 - 呼び出す必要がある特定の Windows API 関数がいくつかあり、それが DllMain DLL_PROCESS_DETACH 呼び出しにつながる可能性がありますか、または任意の命令で発生する可能性がありますか?
6. DllMain DLL_PROCESS_DETACH 呼び出しをいつでも「注入」でき、コール スタックの上位の関数が実行されなくなった場合、コール スタックの上位の関数が中断された場所を正確に知るにはどうすればよいでしょうか? したがって、DllMain 内で関数によって割り当てられたハンドルまたはリソースをスタック上で解放することができます。
7. DllMain DLL_PROCESS_DETACH への呼び出しを一時的に防止/延期する方法はありますか? 呼び出し/割り込みが同じスタックで発生した場合、ロックは明らかに役に立ちません。

残念ながら、フック解除中に DllMain でこのような状況が発生する前に、フック (およびフック解除) コードを複数のコンピューターで数か月実行していたため、これらの質問を実験的に解決することはおそらくできません。なんらかの理由で、4つの異なるプログラムで同時に発生しました...

また、十分な評判を持っている人が「再入可能」と「再入可能」のタグをマージしてくれませんか?