什么可能导致 wxFrame::Destroy() 不破坏任何东西？答案

【问题标题】：What may cause wxFrame::Destroy() to not to destroy anything?什么可能导致 wxFrame::Destroy() 不破坏任何东西？
【发布时间】：2018-12-06 09:23:55
【问题描述】：

我完全清楚我的问题没有明确的解决方案，这就是为什么我不问为什么它不起作用，而是问预期的行为是什么/当前的实现是如何工作的：

我有一个带有很多子 GUI 元素的 wxFrame 派生类。关闭时调用 wxFrame::Destroy() 并且我最终不仅在我的 wxFrame 派生类的析构函数中，而且在所有这些子元素的析构函数中。在这种情况下，我的所有窗口都已关闭，应用程序正常退出。

现在在某些情况下这不起作用：我可以通过 wxFrame::Destroy()，它和往常一样做，但之后没有调用析构函数，应用程序保持活动和可见。在这种情况下，我可以尝试多次关闭/调用 wxFrame::Destroy()，结果始终相同，应用程序保持活动状态，所有窗口仍然可见且可用。

我个人猜测，这与我的一个子元素有关，但我不知道是哪一个/什么会导致这种行为。

所以我的问题是：wxFrame::Destroy() 打算如何工作，在什么情况下它会拒绝这样的调用并且不会破坏相关的 wxFrame？

【问题讨论】：

你设置了什么条件来显示这种行为？你展示的一些代码会很好。注意：wxFrame 使用延迟销毁，所以所有挂起的事件都在调用析构函数之前处理。见docs

标签： wxwidgets

【解决方案1】：

wxFrame::Destroy() 不会立即销毁窗口，它只是将其标记为删除，这将在下一次消息循环迭代期间实际发生，在处理完所有未决消息之后（这很重要，因为其中一些未决消息可能有处理程序引用即将被删除的框架）。因此，对您所描述的此类问题的最常见解释是，某些事物生成事件的速度比处理它们的速度快，因此消息循环永远不会空闲。

例如，在旧版本的 wxWidgets 中，如果您没有正确地重新绘制所有窗口，即没有在您的绘制处理程序中创建 wxPaintDC，则 MSW 下的 wxEVT_PAINT 事件可能会发生这种情况。 wxWidgets 3 添加了一些解决方法来防止这种确切情况的发生，但仍然可能发生稍微复杂一些的事情。

要对此进行调试，运行 Spy++ 应用程序并检查您是否在应用程序窗口中看到永无止境的 Windows 消息流会很有用。

【讨论】：