Hello DJ,
Well after a bit of playing I got it so you can veto the
close of a floating pane "properly" I think This patch
replaces the previous one so start from a clean source.
<snip>
def OnClose(self, event):
+ e = FrameManagerEvent(wxEVT_AUI_PANEBUTTON)
+ e.SetPane(self._owner_mgr.GetPane(self._pane_window))
+ e.SetButton(PaneInfo.buttonClose)
+ self._owner_mgr.ProcessMgrEvent(e)! #self._owner_mgr.OnFloatingPaneClosed(self._pane_window)
! #self.Destroy()! #self._mgr.UnInit()
This is more likely, but I still see one source of problem. By removing this line:
! #self.Destroy()
The MiniFrame used to actually float the pane is no more destroyed. It is simply hidden by the call to Hide() inside OnPaneButton(), but it's still alive with all its event handlers listening (because UnInit() has not be called). Now, I don't know how wxPython react when it has to deal with an increasing number of floating hidden wx.MiniFrames (wx.Frames on GTK), but surely enough the presence itself of these randomly walking mini frames in the app should not be allowed, in my opinion.
Maybe Robin can shed some light on this problem.
Andrea.
···
_________________________________________
Andrea Gavana (gavana@kpo.kz)
Reservoir Engineer
KPDL
4, Millbank
SW1P 3JA London
Direct Tel: +44 (0) 20 717 08936
Mobile Tel: +44 (0) 77 487 70534
Fax: +44 (0) 20 717 08900
Web: http://xoomer.virgilio.it/infinity77
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯