私は真実であると確信しています。私がWindows SendMessage()を使用するとき、これは決まった他のメッセージによって先取りされる可能性があるので、確定的でないPostMessage()とは対照的に、即座に実行される（メッセージが処理されるまで返されない）その瞬間のキュー（実際にはメッセージループに当たるまで実行されません）。Windowsメッセージとその確定的なプロパティ
これは公正な評価ですか、それとも不足していますか？
これは、インプロセスコールでは本質的に真です。プロセス間のSendMessageも同様ですが、受信者プロセスがGetMessage（またはその親子）を呼び出すまで、メッセージの処理は開始されません。
あなたのUIスレッドが何かのように見えるメッセージポンプがあります。
while (GetMessage(&msg))
DispatchMessage(&msg);
のPostMessageはメッセージがメッセージ・キューに入れられるようになります。 GetMessageは、キューから最も古いメッセージ（FIFO *）を削除します。
DispatchMessageにより、メッセージのターゲットウィンドウに関連付けられたWndProcがメッセージとともに呼び出されます。
SendMessageは基本的にこのチェーンをバイパスし、WndProcを直接（多かれ少なかれ）呼び出します。
多くの標準的なウィンドウメッセージは、1つのメッセージを送信する別のメッセージを送信し、別のメッセージを送信する一連のSendMessageコールをもたらします。その連鎖はしばしば「現在のディスパッチ」と呼ばれます。チェーン内でメッセージを処理する必要がある場合は、SendMessageを使用してください。現在のディスパッチが完了した後で処理する必要がある場合は、PostMessageを使用してください。
Spy++のようなツールを使用すると、Windowsのメッセージングの動作を確認したり、操作のメッセージの順序で問題をデバッグすることができます。
[*]特定の種類のメッセージ（つまり、タイマー、マウス、キーボード）がキューに実際には掲載されず、その場で生成されるため、厳密にはFIFOキューではありません。簡単にするために、FIFOと考えることができます。