My mind is boggling here and I hope that someone can help me out.
I'm writing an application that has a ListCtrl inside a Panel inside
a ScrolledWindow. I want to click on an item on the list, and have
another ListCtrl inside a Panel beside it (with the Panel's parent being
the same ScrolledWindow). I want to click around on that second
Panel/ListCtrl. Then, if I click on another item in the first ListCtrl, I
want the second Panel/ListCtrl to be destroyed and another Panel/ListCtrl
combo appears in it's place and I want to click around on that third
Panel/ListCtrl.
In an Ideal World, this would work great. In the Real World, what happens
is that I can click on the first ListCtrl to create the second. But when
I click on another item in the first ListCtrl, the new ListCtrl appears
correctly, but I can't click on anything. My gut feeling is that the
ListCtrl/Panel is not being destroyed. This is how I have it in my code:
def removeLists(self):
# self is the first panel
# self.next is the second panel
if self.next:
self.parent.sizer.Remove(window)
self.next.DestroyChildren()
if not window.Destroy():
print "### Window not destroyed!"
I just finished reading the "Window deletion overview" but it really didn't
tell me anything I hadn't figured out and have tried the Close method, but got the same results.
I'm writing an application that has a ListCtrl inside a Panel inside
a ScrolledWindow. I want to click on an item on the list, and have
another ListCtrl inside a Panel beside it (with the Panel's parent being
the same ScrolledWindow). I want to click around on that second
Panel/ListCtrl. Then, if I click on another item in the first ListCtrl, I
want the second Panel/ListCtrl to be destroyed and another Panel/ListCtrl
combo appears in it's place and I want to click around on that third
Panel/ListCtrl.
...
def removeLists(self):
# self is the first panel
# self.next is the second panel
if self.next:
self.parent.sizer.Remove(window)
self.next.DestroyChildren()
if not window.Destroy():
print "### Window not destroyed!"
What is window?
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
this is what happens when you edit and condense you code in email. =)
This should make more sense . .
def removeLists(self):
# self is the first panel
# self.next is the second panel
if self.next:
self.parent.sizer.Remove(self.next)
self.next.DestroyChildren()
if not self.next.Destroy():
print "### Window not destroyed!"
-- mikeh
···
On Wed, Jan 16, 2002 at 12:51:17PM -0800, Robin Dunn wrote:
this is what happens when you edit and condense you code in email. =)
This should make more sense . .
def removeLists(self):
# self is the first panel
# self.next is the second panel
if self.next:
self.parent.sizer.Remove(self.next)
self.next.DestroyChildren()
if not self.next.Destroy():
print "### Window not destroyed!"
Okay, that does make more sense.
First off, you shouldn't need the DestroyChildren call as the wxWindow
destructor will take care of that for you, and for non top-level windows the
Destroy call unconditionally returns TRUE, so you don't need the if
statement. Of course probably neither of these will help with your
trouble...
I don't see anything wrong with what you are doing and would expect it to
work. The only thing I can suggest is to try simplify it into a small
sample and try to figure out what's going on there.
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
I don't see anything wrong with what you are doing and would expect it to
work. The only thing I can suggest is to try simplify it into a small
sample and try to figure out what's going on there.
I ran my app on a Linux box and the destroying the Panel/List windows
working fine. I made a simplier example and made sure that I got the
same functionality on my Linux box. As soon as I verify that lack of
destroying windows is a MS-Windows problem, I'd going to submit a bug . .
. . . but who should I submit it to -- wxPython or wxWindows??
I ran my app on a Linux box and the destroying the Panel/List windows
working fine. I made a simplier example and made sure that I got the
same functionality on my Linux box. As soon as I verify that lack of
destroying windows is a MS-Windows problem, I'd going to submit a bug . .
But the sample app worked fine in Win32 . . .
So -- I looked what I did different and found my bug. Not sure *why* it
worked in wxGTK now . . .
> I don't see anything wrong with what you are doing and would expect it
to
> work. The only thing I can suggest is to try simplify it into a small
> sample and try to figure out what's going on there.
I ran my app on a Linux box and the destroying the Panel/List windows
working fine. I made a simplier example and made sure that I got the
same functionality on my Linux box. As soon as I verify that lack of
destroying windows is a MS-Windows problem, I'd going to submit a bug . .
. . . but who should I submit it to -- wxPython or wxWindows??
They both share the same bug tracker.
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
> I ran my app on a Linux box and the destroying the Panel/List windows
> working fine. I made a simplier example and made sure that I got the
> same functionality on my Linux box. As soon as I verify that lack of
> destroying windows is a MS-Windows problem, I'd going to submit a bug .
.
But the sample app worked fine in Win32 . . .
So -- I looked what I did different and found my bug. Not sure *why* it
worked in wxGTK now . . .
What was the bug?
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
In my app, I was only destroying the ListCtrl. In the example app, I was
destroying the Panel (which is the parent of the ListCtrl).
It makes sense why things got funky and with my app's code, an easy
mistake. I simplified the code for the removing of the windows and fixed
it, and it works great.
-- mikeh
···
On Thu, Jan 17, 2002 at 10:09:41AM -0800, Robin Dunn wrote:
> So -- I looked what I did different and found my bug. Not sure *why* it
> worked in wxGTK now . . .