TopWindow wxFrame deletion doesn't trigger app exit on Linux?

I'm testing a new release of wxoo on Red Hat Linux 8 (wxPython 2.4.0.2, Python 2.2.2).

One of my test apps is a simple frame that embeds a property-editing grid in a wxFrame. When I go to exit this app by clicking on the "x" in the corner of the frame, the frame is destroyed (I added a __del__ to check, and it is called), but the app does not exit (Python continues to run, and needs to be killed with a "killall python").

I've done the SetTopWindow(frame) call, so AFAICS wxPython _should_ be closing the app (it does if I don't add the property-editing grid as a child, BTW).

Does the linux version do something silly like looking to see if _all_ objects are explicitly deleted before exiting? (e.g. if there are colours, icons, or possibly a wxGrid still alive, will it continue to run?)

Thoughts appreciated,
Mike

···

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Mike C. Fletcher wrote:

Does the linux version do something silly like looking to see if _all_ objects are explicitly deleted before exiting? (e.g. if there are colours, icons, or possibly a wxGrid still alive, will it continue to run?)

All the ports will behave this way if there are any toplevel windows that still exist. Ensure that all your dialogs have been Destroy()'ed and that there are no frames that have been hidden and not Close()'d, or if you catch EVT_CLOSE that you either call event.Skip() or self.Destroy().

···

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

Is there a way to get a list of all the frames from wxApp, or something
like that? Then we could print that out in our shutdown code and know
what was still around...

···

On Monday 28 April 2003 12:28 pm, Robin Dunn wrote:

All the ports will behave this way if there are any toplevel windows
that still exist. Ensure that all your dialogs have been
Destroy()'ed and that there are no frames that have been hidden and
not Close()'d, or if you catch EVT_CLOSE that you either call
event.Skip() or self.Destroy().

--
Chuck
http://ChuckEsterbrook.com

There is only the one frame, (with no EVT_CLOSE, and the wxGrid is a child of the frame), and there are no dialogs created. No top-level window is ever hidden. There are definitely colours, icons and the like which are not cleaned up (they exist in class or module namespaces), but no top-level windows.

I'll have to try poking around more to see what's causing it (sigh),
Mike

Robin Dunn wrote:

···

Mike C. Fletcher wrote:

Does the linux version do something silly like looking to see if _all_ objects are explicitly deleted before exiting? (e.g. if there are colours, icons, or possibly a wxGrid still alive, will it continue to run?)

All the ports will behave this way if there are any toplevel windows that still exist. Ensure that all your dialogs have been Destroy()'ed and that there are no frames that have been hidden and not Close()'d, or if you catch EVT_CLOSE that you either call event.Skip() or self.Destroy().

--
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Chuck Esterbrook wrote:

···

On Monday 28 April 2003 12:28 pm, Robin Dunn wrote:

All the ports will behave this way if there are any toplevel windows
that still exist. Ensure that all your dialogs have been
Destroy()'ed and that there are no frames that have been hidden and
not Close()'d, or if you catch EVT_CLOSE that you either call
event.Skip() or self.Destroy().

Is there a way to get a list of all the frames from wxApp, or something like that? Then we could print that out in our shutdown code and know what was still around...

Not yet.

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