Don't assume the dialog is mode-less and call Destroy() from within a
dialog method. This will most assuredly crash if the dialog is shown
modally or quasi-modally.
Don't leak memory for mode-less dialogs created on the stack. Make sure
when the parent frame window is closed that all mode-less dialog memory
is cleaned up. Dialogs are not child windows like controls and toolbars
so their memory does not automatically get cleaned up when the parent
window is destroyed.
Do not directly access frame parent window's pointer in dialog destructors.
Apparently the tear down order when destroying mode-less dialogs is not
guaranteed so the parent window may get deleted before the dialog causing
a crash when accessing the parent window pointer from the dialog dtor.
Do not close mode-less dialogs in the parent frame's destructor. This
doesn't guarantee that the dialog(s) will be destroyed before the parent
but it may reduce some careless mode-less dialog event handling in the
future.
Some of these are due to moving to wxWidgets 3.2, but I'm not sure
all of them are. In particular, the need for CallAfter() in the
search pane's selection handler is probably just a wxWidgets bug on
Mac (the control lies about the current selection inside the event
handler).
Also sets better column widths in the search pane.
Wayne Stambaugh
Jeff Young
Marek Roszko
jean-pierre charras