4

Windows は、SendMessage が返すべきことをどの程度正確に判断するのでしょうか?つまり、受信スレッドが送信メッセージの処理を終了したことをどのように判断するのでしょうか?

詳細なシナリオ: スレッド A が SendMessage を使用してスレッドをスレッド B に送信しています。明らかに、スレッド B がメッセージの処理を完了するまで、SendMessage は戻りません。スレッド B がダイアログ ボックスをポップアップ表示し、メッセージの送信を開始します。私のシナリオでは、スレッド B によってポンプされるキューに WM_KILLFOCUS メッセージがあります。この結果、スレッド B で WM_COMMAND メッセージが生成されます。スレッド B は、この WM_COMMAND メッセージをデフォルトのウィンドウ プロシージャに渡します。これを行うと、元のメッセージの処理がまだ終わっていなくても、SendMessage はスレッド A に戻ります。何が起こっている？どういうわけか、デフォルトのウィンドウ プロシージャがウィンドウを混乱させて、元の送信メッセージが終了したと考えさせているようです。

メッセージをポンピングしてデフォルトのウィンドウ プロシージャを呼び出すと、SendMessage がだまされて返される既知のシナリオはありますか?

ありがとう！フィル

4

4 に答える 4

4

メッセージの処理が開始されている限り、スレッド間メッセージを処理する WindowProc は ReplyMessage を呼び出して、呼び出し元のスレッドが処理を続行できるようにすることができます。

于 2009-12-10T20:49:15.603 に答える
2

戻り値があるためSendMessage、常にメッセージが処理された後です。

PostMessage一方、メッセージが処理されるのを待ちません。

SendMessageの MSDN から:

SendMessage 関数は、指定されたウィンドウのウィンドウ プロシージャを呼び出し、ウィンドウ プロシージャがメッセージを処理するまで戻りません。

メッセージが処理される前に返されることはありません。

于 2009-12-10T16:54:35.187 に答える
1

MSDN によると、スレッド B でダイアログ ボックスを表示するとデッドロックが発生する可能性があることが問題のようです。メッセージのデッドロックを参照してください。

おそらく、スレッド A が受信したメッセージがキューに入れられていないメッセージだったことが原因です。MSDN から:

ただし、送信スレッドは、メッセージが処理されるのを待っている間、キューに入れられていない着信メッセージを処理します。これを防ぐには、SMTO_BLOCK を設定して SendMessageTimeout を使用します。キューに入れられていないメッセージの詳細については、「キューに入れられていないメッセージ」を参照してください。

于 2009-12-10T17:08:15.107 に答える
0

元の SendMessage が返されていないように聞こえますが、送信されたメッセージの処理中にスレッド A の WindowProc が呼び出されたのではありません。メッセージ ハンドラーがメッセージの受信に応答して SendMessage を呼び出すことを控える必要はありません。

フォーカス変更メッセージに応答して送信した WM_COMMAND を受信した時点で、コールスタック内の SendMessage への元の呼び出しを確認できるはずです。

于 2009-12-10T17:05:22.620 に答える