Are you using ‘Destroy’ on the top-level window? Try using ‘DestroyLater’ instead and see if that cures it. This will keep the C++ parts around until all of their events have been processed, which is typically the cause of such errors.
Eric
···
On Monday, February 11, 2019 at 3:36:04 PM UTC-8, Demetrios Tsillas wrote:
Hi folks,
I am porting my app to 4.0.4 (from 3.0) and so far its been easy.
Another possibility is to check self.IsBeingDeleted() and bypass the rest of the handler if it returns True.
···
On Tuesday, February 12, 2019 at 8:21:37 AM UTC-8, efahl wrote:
Jim,
Are you using ‘Destroy’ on the top-level window? Try using ‘DestroyLater’ instead and see if that cures it. This will keep the C++ parts around until all of their events have been processed, which is typically the cause of such errors.
The TreeCtrl is being destroyed as part of the destruction of the parent, which is a Frame. Changing the parent’s Destroy to a DestoryLater did not fix the problem.
I also tried deleting the TreeCtrl explicitly with DestroyLater and setting the parent’s reference to it to None. This didn’t help either.
I then tried adding:
if self.IsBeingDeleted():
return
to the OnTreeSelChanged() handler. But the problem is that the underlying C obj has already been deleted so I get an error on the call to IsBeingDeleted.
On Tuesday, February 12, 2019 at 8:21:37 AM UTC-8, efahl wrote:
Jim,
Are you using ‘Destroy’ on the top-level window? Try using ‘DestroyLater’ instead and see if that cures it. This will keep the C++ parts around until all of their events have been processed, which is typically the cause of such errors.
Another possibility is to check self.IsBeingDeleted() and bypass the rest of the handler if it returns True.
–
Robin
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
What worked is to call self.tree_list.Unbind(wx.EVT_TREE_SEL_CHANGED) just before calling Destroy on the parent.
···
On Wed, Feb 13, 2019 at 10:32 PM Demetrios Tsillas jtsillas@gmail.com wrote:
The TreeCtrl is being destroyed as part of the destruction of the parent, which is a Frame. Changing the parent’s Destroy to a DestoryLater did not fix the problem.
I also tried deleting the TreeCtrl explicitly with DestroyLater and setting the parent’s reference to it to None. This didn’t help either.
I then tried adding:
if self.IsBeingDeleted():
return
to the OnTreeSelChanged() handler. But the problem is that the underlying C obj has already been deleted so I get an error on the call to IsBeingDeleted.
On Tuesday, February 12, 2019 at 8:21:37 AM UTC-8, efahl wrote:
Jim,
Are you using ‘Destroy’ on the top-level window? Try using ‘DestroyLater’ instead and see if that cures it. This will keep the C++ parts around until all of their events have been processed, which is typically the cause of such errors.
Another possibility is to check self.IsBeingDeleted() and bypass the rest of the handler if it returns True.
–
Robin
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
The TreeCtrl is being destroyed as part of the destruction of the parent,
which is a Frame. Changing the parent's Destroy to a DestoryLater did not
fix the problem.
I also tried deleting the TreeCtrl explicitly with DestroyLater and setting
the parent's reference to it to None. This didn't help either.
What happens if you do use .DestroyLater() but _don't_ set to None ?
I then tried adding:
if self.IsBeingDeleted():
return
to the OnTreeSelChanged() handler. But the problem is that the underlying C
obj has already been deleted so I get an error on the call to
IsBeingDeleted.
Does it help to test the item inside the handler ?
if not item.IsOk():
return
Karsten
···
On Wed, Feb 13, 2019 at 10:32:46PM -0500, Demetrios Tsillas wrote:
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B