Window Deletion Overview¶Window deletion can be a confusing subject, so this overview isprovided to help make it clear when and how you delete windows, orrespond to user requests to close windows.
When the user clicks on the system close button or system closecommand, in a frame or a dialog, wxPython callswx.Window.Close. This in turn generates anwx.EVT_CLOSEevent: see wx.CloseEvent.
It is the duty of the application to define a suitable event handler,and decide whether or not to destroy the window. If the application isfor some reason forcing the application to close(wx.CloseEvent.CanVeto returnsFalse), the window shouldalways be destroyed, otherwise there is the option to ignore therequest, or maybe wait until the user has answered a question beforedeciding whether it is safe to close. The handler forwx.EVT_CLOSEshould signal to the calling code if it does not destroy the window,by callingwx.CloseEvent.Veto. Calling this provides usefulinformation to the calling code.
The wx.CloseEvent handler should only callwx.Window.Destroy to delete the window, and not use thedeloperator. This is because for some window classes, wxPython delaysactual deletion of the window until all events have been processed,since otherwise there is the danger that events will be sent to anon-existent window.
As reinforced in the next section, callingClose does not guaranteethat the window will be destroyed. Callwx.Window.Destroy ifyou want to be certain that the window is destroyed.
Your application can either usewx.Window.Close event just asthe framework does, or it can callwx.Window.Destroy directly.If usingClose(), you can pass aTrue argument to this functionto tell the event handler that we definitely want to delete the frameand it cannot be vetoed.
The advantage of usingClose instead ofDestroy is that it willcall any clean-up code defined by thewx.EVT_CLOSE handler; forexample it may close a document contained in a window after firstasking the user whether the work should be saved.Close can bevetoed by this process (returnFalse), whereasDestroydefinitely destroys the window.
The default close event handler for wx.Dialog simulates aCancel command, generating awx.ID_CANCEL event. Since thehandler for this cancel event might itself callClose, there is acheck for infinite looping. The default handler forwx.ID_CANCELhides the dialog (if modeless) or callsEndModal(wx.ID_CANCEL) (ifmodal). In other words, by default, the dialog is not destroyed.
The default close event handler for wx.Frame destroys the frameusingDestroy().
What should I do when the user calls upExit from a menu? You cansimply callwx.Window.Close on the frame. This will invokeyour own close event handler which may destroy the frame.
You can do checking to see if your application can be safely exited atthis point, either from within your close event handler, or fromwithin your exit menu command handler. For example, you may wish tocheck that all files have been saved. Give the user a chance to saveand quit, to not save but quit anyway, or to cancel the exit commandaltogether.
A wxPython application automatically exits when the last top levelwindow ( wx.Frame or wx.Dialog), is destroyed. Put anyapplication-wide cleanup code inwx.AppConsole.OnExit (this isa method, not an event handler).
Child windows are deleted from within the parent destructor. Thisincludes any children that are themselves frames or dialogs, so youmay wish to close these child frame or dialog windows explicitly fromwithin the parent close handler.
So far we’ve been talking about ‘managed’ windows, i.e. frames anddialogs. Windows with parents, such as controls, don’t have delayeddestruction and don’t usually have close event handlers, though youcan implement them if you wish. For consistency, continue to use thewx.Window.Destroy method instead of thedel operator whendeleting these kinds of windows explicitly.
