我绝对意识到没有一个明确的解决方案可以解决我的问题，这就是为什么我不问为什么它不起作用，而是预期的行为是什么/如何指定当前实现起作用的原因：
我有一个wxFrame派生类，其中包含许多子GUI元素。在关闭时，调用了wxFrame :: Destroy（），不仅导致我的wxFrame派生类的析构函数出现，而且最终出现在所有这些子元素的析构函数中。在这种情况下，我所有的窗户都关闭了，应用程序可以正常退出。
现在在某些情况下这是行不通的：我可以通过wxFrame :: Destroy（）进行步进，它的操作与往常相同，但是此后没有调用解扰器，该应用程序仍然有效且可见。在这种情况下，我可以尝试多次关闭/调用wxFrame :: Destroy（），结果始终是相同的，应用程序仍处于活动状态，所有窗口仍然可见且可用。
我个人会猜测，这与我的一个子元素有关，但我不知道哪个/什么可能导致这种行为。
所以我的问题是：wxFrame :: Destroy（）打算如何工作，在什么条件下它会拒绝这样的调用并且不会破坏相关的wxFrame？
答案 0 :(得分：1)
wxFrame::Destroy()不会立即销毁该窗口，它只是将其标记为删除，这实际上将在处理所有未决消息之后的下一个消息循环迭代期间发生（这很重要，因为其中一些未决消息可能有处理程序引用即将删除的框架）。因此，对于您正在描述的这种问题，最常见的解释是，某些东西生成事件的速度快于事件的处理速度，因此消息循环永远不会变得空闲。
例如，在较旧的wxWidgets版本中，如果您未正确地重新绘制所有窗口，即未在绘制处理程序中创建wxEVT_PAINT，则MSW下的wxPaintDC事件可能会发生。 wxWidgets 3添加了一些变通办法，可以防止这种情况的发生，但仍可能会发生一些更为复杂的事情。
要调试此功能，运行Spy ++应用程序并检查是否在应用程序窗口中看到无休止的Windows消息流会很有用。