Window deletion overview

wxPython Users
1

From the docs:

The EVT_WINDOW_DESTROY event is sent from the wx.Window destructor
when the GUI window is destroyed.

When a class derived from wx.Window is destroyed its destructor
will
have already run by the time this event is sent. Therefore this event
will not usually be received at all by the window itself. Since it is
received after the destructor has run, an object should not try to
handle its own wx.WindowDestroyEvent, but it can be used to get
notification of the destruction of another window.

This explains why I am receiving EVT_WINDOW_DESTROY when my window
is not being destroyed. Instead it apparently indicates that a
child window has been destroyed. The documentation doesn’t
offer an alternative.

Okay, so here is my question: Is there any way to handle the
imminent destruction of a window? In other words, is there a reliable
place to put clean up code that will be called immediately before a
window is destroyed? Or during the process of destruction, possibly
after the the underlying window object is destroyed?

The kind of clean up I am talking about here is cleanup that must
happen in all cases (hence EVT_CLOSE won’t do).

I have read the Window Deletion Overview, but it doesn’t
address my question:
http://www.wxwidgets.org/manuals/stable/wx_windowdeletionoverview.html#windowdeletionoverview
I’d be happy to update this document if I get solution.

The following answers are incorrect, so I am hoping for
something different:

Incorrect answer #1: EVT_CLOSE - This message indicates a requestto close a window (e.g. the user has just clicked the close
button). It will not necessarily precede a windows destruction. It is
just plain wrong to put any final clean up code in an EVT_CLOSE
handler, though it is fine to put things like optional “Save Changes”
logic in EVT_CLOSE.

Incorrect answer #2: del - The window instance will not
be garbage collected at the right time. Using del for this kind of
thing is just plain wrong.

Incorrect answer #3: EVT_WINDOW_DESTROY in the parent window.
Well that might work, but it’s a pretty lame solution because the
parent window shouldn’t have to know the implementation details and
needs of the windows that are contained within it. If I were
implementing a reusable widget of some kind, I wouldn’t want to require
the parent window to have to do special clean up for it.
Any other options? Or are any of my “incorrect answers” actually
correct?
It seems to me that this is a core design flaw in wxWidgets, since
the ability to clean up gracefully when a window is destroyed is a
rather
fundamental expected capability in a GUI, though it is usually possible
to do some ugly hack to get around this flaw. It would be very nice if
EVT_WINDOW_DESTROY were to be the last message in a windows
message queue before it is destroyed. Unfortunately such a change
would
not be backward compatible, so maybe a new message id is needed
(perhaps EVT_DESTROY, where EVT_WINDOW_DESTROY would be deprecated but
maintain it’s current semantics). The Window Deletion Overview
says “for some window classes, wxWidgets delays actual deletion of
the window until all events have been processed” so Destroy would
first place EVT_DESTROY at the end of the message queue, and then do
what it does now.

Ken

2

Ken Seehart wrote:

*Incorrect answer #3:* EVT_WINDOW_DESTROY in the parent window. Well that might work, but it's a pretty lame solution because the parent window shouldn't have to know the implementation details and needs of the windows that are contained within it. If I were implementing a reusable widget of some kind, I wouldn't want to require the parent window to have to do special clean up for it.

Untested, but how about something like this:

         self.GetParent().Bind(wx.EVT_WINDOW_DESTROY, self.OnCheckDestroy)

     def OnCheckDestroy(self, evt):
         evt.Skip()
         if self is evt.GetEventObject():
             self.DoMyDestroyStuff()

IOW, hook the parent's event, but process it in the child.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

3

Robin Dunn wrote:

Ken Seehart wrote:

*Incorrect answer #3:* EVT_WINDOW_DESTROY in the parent window. Well that might work, but it's a pretty lame solution because the parent window shouldn't have to know the implementation details and needs of the windows that are contained within it. If I were implementing a reusable widget of some kind, I wouldn't want to require the parent window to have to do special clean up for it.

Untested, but how about something like this:

        self.GetParent().Bind(wx.EVT_WINDOW_DESTROY, self.OnCheckDestroy)

    def OnCheckDestroy(self, evt):
        evt.Skip()
        if self is evt.GetEventObject():
            self.DoMyDestroyStuff()

IOW, hook the parent's event, but process it in the child.

Good idea, but it doesn't seem to work for me. I don't know why. It seems like it should work. But I seem to be having various problems with window destruction.

The parent window is an AuiMDIChildFrame, and I think that might have something to do with it. I'm thinking of dropping AuiMDI in favor of AUI_DockingWindowManager in which case I need to figure out how to get all the notebook tabs features that are in AuiMDI.

Ken