在上一篇文章中，我们讲解了通过投递一个无意义的消息来解决EndManualModalDialog调用相关的问题。今天的文章中，我们将会通过另外一种方法，以一种完全不同的方式来解决相同的问题。

我们的想法是，确保模态对话框的消息循环重新获得控制权，即使发生的所有事情都是传入的已发送消息，以便它可以检测到fEnded标志已设置并能够退出消息循环。

我们将修改模态消息循环代码，而不是像上一篇文章中的那样修改EndManualModalDialog 函数，且看代码如下：

 

在上面的代码中，我们将对GetMessage的调用改为了PeekMessage，并将已经阅览过的消息从消息队列中移除。这个函数和GetMessage一样，它会分发消息队列中的发送型消息，然后检查队列中是否有投递型消息。不同之处在于，如果消息队列中没有投递型消息，GetMessage 会一直等待，而 PeekMessage 会返回并告诉你没有投递型消息。

这就是我们想要的效果。如果PeekMessage告诉我们消息队列中没有投递型消息，为了谨防发送型消息处理例程中修改了fEnded标志，我们可以借此机会再次检查下它。
如果没有，则我们调用WaitMessage函数一直等待，直到有事情要做(收到一条发送型消息或者投递型消息)。

课后练习：如果重点是在发送型消息分发后重新获得控制权，为什么不在DispatchMessage 返回后立即测试fEnded标志？

总结

一直没时间搞懂GetMessage和PeekMessage的区别，可能心里老是觉得：”那是条硬骨头，应该很难啃吧?”
但是，治学，不弄明白究竟，终将是不会到达你想要的层次。
大好时光一去不复返，应该将它投入到有意义的地方。
你愿意嗑瓜子还是长跑？

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《The dialog manager, part 7: More subtleties in message loops》