MFC中当前消息实例结束后发消息及直接调用按钮函数的合规性

一、当前消息处理未终止时使用PostMessage是否可行？ #

先说结论：是可行的，但得先搞懂Windows消息队列的工作逻辑。

当你在OnFilePublicTalk里调用PostMessage(WM_COMMAND, ID_FILE_PUBLIC_TALK, 0)时，这个消息会被放到当前线程的消息队列末尾，不会打断正在执行的OnFilePublicTalk函数——只有等当前函数完全执行完毕，消息循环回到队列取消息时，这个新的WM_COMMAND才会被处理，触发下一轮OnFilePublicTalk调用。

你之前加两个PostMessage出问题，大概率是因为连续发送的消息在处理时，对话框的状态（比如m_pEntry、m_iDateIndex这些变量）还没来得及完成更新，导致后续函数调用拿到了不一致的状态。这种情况要么得确保状态更新完成后再发消息，要么就像你后来做的那样，改用更直接的方式。

二、直接调用按钮处理函数是否合规可接受？ #

完全合规，而且在你的场景下是更稳妥的选择。

MFC的消息处理函数（比如OnBnClickedMfcbuttonPreviousDate、OnBnClickedMfcbuttonNextDate）本质上就是对话框类的普通成员函数，只是被MFC的消息映射机制绑定到了对应的控件点击消息而已。直接调用这些函数，和你自己写个工具函数然后调用没任何区别——只要你的函数逻辑不依赖消息的WPARAM/LPARAM参数（从你的代码看，这些按钮处理函数就是直接操作对话框状态、更新HTML并重绘Web控件，没用到消息参数），那直接调用绝对安全。

比起PostMessage，直接调用有几个明显优势：

• 同步执行，状态更新立即生效，不会出现消息队列延迟导致的界面状态不一致；
• 避开了消息队列里可能的消息顺序问题；
• 调试起来更直观，不用跟踪消息队列的处理流程。

从你的代码场景来看，你需要在处理完CWeekendMeetingDlg的结果后，立即更新日期再重新触发OnFilePublicTalk，直接调用按钮处理函数能确保状态同步更新，之后再用delay_post_msg延迟发消息重新打开对话框，这个逻辑非常合理。

总结 #

• 用PostMessage在当前消息处理未结束时触发事件是可行的，但要注意状态的一致性；
• 直接调用MFC的消息处理函数是合规且推荐的，尤其是需要同步执行状态更新逻辑时，比模拟消息发送更可靠。

内容的提问来源于stack exchange，提问作者Andrew Truckle