对MFC消息机制又糊了,明白的解释下这个消息处理过程

Question

1.我做了这样一个试验，MainFrm处理APP SendMessage()过来的消息X，在MainFrm处理X消息函数中向ChildFrm SendMessage()消息A，
childFrm在处理消息A的函数中，先向MainFrm SendMessage(消息B），再PostMessage(消息C），然后返回。结果是：先处理消息B，再处理消息C，最后消息A处理结束返回。  把B、C消息顺序对换，处理结果也相应对换。这样的话，PostMessage()除了返回值的意义不同外（一个是函数返回值 ，一个是BOOL型，表示是否发送成功），跟SendMessage()有什么不同呢？
2，在消息C中使用Sleep(),可以看到整个程序界面都是假死状态，可推断这些消息的处理都在一个线程中。
，另外，是否可这样理解，MainFrm在处理消息X时，在未返回前，仍然能响应其它的消息？如果使用消息队列的话，这是如何实现的？
我只能理解是SendMessage(), PostMessage()只是调用各个窗口的消息函数而已，只不过一个取返回值 ，一个忽略返回值。

Answer 1

sendmessage直接立即调用
postmessage是放入消息队列

Answer 2

sendMessage是立即调用,等待函数执行完成然后返回,你在C中执行Sleep,所以不会先执行C函数,.
postmessage是投递消息,只负责把消息传递给窗口过程,不会等待消息执行完.我也是初学,相互交流..

Answer 3

就是说SendMessage不会将消息放入消息队列？？那我把APP也改成PostMessage(X)给MainFrm, 结果还是一样
理论上MainFrm应该在执行完X的响应该函数后，再执行C的响应函数

Answer 4

1.
结果是：先处理消息B，再处理消息C，最后消息A处理结束返回。
=============================
当消息B处理完成之后，发现消息队列中还有个消息C没有处理，处理之。
当消息C处理完成之后，发现消息队列中是空的，发现消息A没处理完，处理之。2.当窗口响应任何消息时，并不能响应其它消息，所以界面会出现假死的情况。

Answer 5

把APP也改成PostMessage(X)给MainFrm
这样改不明显
先向MainFrm SendMessage(消息B），再PostMessage(消息C）
------------------------------------------------
这里，两个都用post,然后换顺序

Answer 6

我的理解：单线程SendMessage(), PostMessage()看不出区别的，多线程就明显了，比如说往另一个线程发消息，SendMessage()是阻塞的，要等待另外一个线程接收，然后处理完才开始继续往下执行，PostMessage()则是非阻塞的，发消息过去，不管对方处理不处理，都继续往下执行 

Answer 7

本线程内SendMessage是立即响应，其它线程SendMessage要经过消息队列并等待，PostMessage在本线程和其它线程都是放入消息队列立即返回。

Answer 8

这个试过了, 结果都是谁先谁执行跟Post,send没关系

Answer 9

汗,新发现, MessageBox()似乎有着神奇的力量,它改变了上面的结果
我是在B、C的处理函数里面用MessageBox来判断它们的执行顺序的，单步调试时，发现在跳入到B的函数里后，竟然不执行MessageBox,下一步直接跳到C的处理函数里=_=!!，这个神奇的问题先不讨论。
我就把MessageBox()都去掉了，加了一个全局变量，在每个执行函数里往这个全局CString里添加字符串，最后得出的结果是：
执行B（SendMessage） -> main return -> 执行C（PostMessage）
这个应该是真实的结果。[color=#FF0000]的确PostMessage应该是放入消息队列，SendMessage应该是不会放入消息队列的了，而是直接执行至返回。

Answer 10

大约8年之前，我也发现messagebox的神奇力量，由此产生了对vc的厌烦感，不过后来没有深究。