这是我在Qt支持论坛上的帖子的x-post，因为我觉得它很奇怪而且很有趣，你们也可以在这里帮助我。
我将尝试解释我遇到的一个问题 - 这是一个非常奇怪的问题，所以当我试图解释它时，请耐心等待。
让我先概述一下我的申请。它是一个简单的“串行数据记录器”类型程序，用Windows XP中的Qt 4.7编写;它基本上接收串行端口上的通信（使用QExtSerialPort），进行一些处理以从这些通信中提取数据，然后将这些数据推送到前端GUI并将其输出到日志文件。我还使用qDebug（）在各个点处将应用程序和数据传递到应用程序输出，这样我就可以监视应用程序内部流动的内容。
为清楚起见，如果您没有使用它，QExtSerialPort只会在串口接收到字节时发出信号，并使用QByteArray将这些信号传递到连接的插槽。
所以现在我的问题 - 我的应用程序最初运行完美，但大约5-10分钟后整个事情锁定并停止工作，迫使我崩溃。
在调试器中对此进行了进一步调查后，我注意到了一件非常奇怪的事情。
通信流是相当稳定的，因此通过监视调试器中的“应用程序输出”窗格，我能够立即看到程序何时锁定，因为似乎没有更多的通信到达。如果在这一点上，我点击并将我的应用程序的窗口拖到屏幕的另一部分，通信开始进入并被处理，然后它停止并再次锁定，直到我再次移动窗口然后它将允许更多数据等等......我已经尝试了一段时间，每次我在屏幕上移动窗口，它都允许程序接收通信和处理。如果我打开窗口的左上角系统菜单（使用ALT空间），这似乎也允许通信在打开时进行处理。
因此，我在这里的有限推论似乎指向了这样的理论：当这些动作中的每一个阻止重新绘制窗口时，GUI /重绘动作必须阻止我的通信进入。
此外 - 使用两个插槽将数据推送到GUI，更有趣的是（我认为）如果我删除了与这些插槽的连接，从而不允许在我的代码中与GUI类交互，则应用程序运行很好，永远不会锁定所有数据，使其成为日志文件和应用程序输出。但是这些插槽非常简单，只检查一些组合框的状态，以决定是否更新一些文本字段。
有没有人见过这样的事情？任何人都对可能发生的事情有任何想法？
答案 0 :(得分：1)
当您拖动窗口或打开QMenu时，会使用临时QEventLoop，并允许您的应用程序接收事件。
这意味着您在代码中的某个位置（或QExtSerialPort）阻止主事件循环执行。