wxPython in Action (EVT_CLOSE)当关闭一个框架时都发生了什么？

 当你关闭一个框架时，它最终消失了。除非这个框架被明确地告诉不关闭。换句话说，那关闭不是直接了当的。在wxPython的窗口部件关闭体系之后的用意是，给正在关闭的窗口部件充足的机会来关闭或释放它所占用任何非wxPython资源。如果你占用了某种昂贵的外部资源，如一个大的数据结构或一个数据库连接，那么该意图是特别受欢迎的。

诚然，在C++ wxWidgets世界里，由于C++不为你管理内在分配的清理工作，管理资源是更严肃的问题。在wxPython中，对于多步的关闭过程的显式需求就很少，但它对于在过程中使用额外的钩子仍然是有用的。（随便说一下，我们在这一节中从单词“框架”切换到单词“窗口部件”是故意的——因为在本节中的所有内容都适用于所有顶级窗口部件，如框架或对话框）。

何时用户触发关闭过程

关闭过程最常由用户触发，如敲击一个关闭框或选择系统菜单中的关闭项或当应用程序响应其它某个事件而调用框架的Close方法。当上述情况发生时，wxPython架构引发一个EVT_CLOSE事件。像wxPython 架构中的其它别的事件一样，你可以在绑定一个事件处理器以便一个EVT_CLOSE事件发生时调用。

如果你不声明你自己的事件处理器，那么默认的行为将被调用。默认的行为对于框架和对话框是不同的。

1、默认情况下，框架处理器调用Destroy()方法并删除该框架和它的所有的组件。

2、默认情况下，对话框的关闭处理器不销毁该对话框——它仅仅模拟取消按钮的按下，并隐藏对话框。该对话框对象仍继续存在在内存中。因此，如果需要的话，应用程序可以从它的数据输入部件获取值。当应用程序完成了对对话框的使用后，应该调用对话框的Destroy()方法。

如果你编写你自己的关闭处理器，那么你可以使用它来关闭或删除任何外部的资源，但是，如果你选择去删除框架的话，显式地调用Destroy()方法是你的责任。尽管Destroy()经常被Close()调用，但是只调用Close()方法不能保证框架的销毁。在一定的情形下，决定不销毁框架是完全可以的，如当用户取消了关闭。然而，你仍然需要一个方法来销毁该框架。如果你选择不去销毁窗口，那么调用关闭事件的wx.CloseEvent.Veto()方法来通知相关部分：框架拒绝关闭，是一个好的习惯。

如果你选择在你的程序的别处而非关闭处理器中关闭你的框架，例如从一个不同的用户事件像一个菜单项，那么我们建议使用的机制是调用框架的Close()方法。这将启动一个和系统关闭行为相同的过程。如果你要确保框架一定被删除，那么你可以直接调用Destroy()方法；然而，如果你这样做了，可能会导致框架所管理的资源或数据没有被释放或保存。

什么时候系统触发关闭过程

如果关闭事件是由系统自己触发的，对于系统关闭或类似情况，你也有一种办法管理该事件。wx.App 类接受一个EVT_QUERY_END_SESSION事件，如果需要的话，该事件使你能够否决应用程序的关闭，如果所有运行的应用已经批准了系统或GUI环境的关闭的话，那么随后会有一个EVT_END_SESSION事件。你选择去否决关闭的行为是与依赖于具体系统的。

最后，值得注意的是，调用一个窗口部件的Destroy()方法不意味该部件被立即销毁。销毁实际上是当事件循环在未来空闲时（任何未被处理的事件被处理之后）才被处理的。这就防止了处理已不存在的窗口部件的事件。