I've tried two things, both of which freeze my computer, to get a
selectable list out to a user's eyes, A ComboBox and a ListBox. Both
are causing freezes; ComboBox, on dropdown, and ListBox, on clicking
within the box. I've run out of ideas for troubleshooting... Details:
- I'm using relatively large lists (~200 items).
- I've left the select events un-bound, to see if it was one of my
methods causing the clog. This fixed nothing.
- Even if there are no other objects in the window, it still causes a
freeze. The hidden objects within the window are negligible.
- Calls to the boxes are basically: 'make list ; create listbox with
choices = list ; put listbox in sizer'. And that's it.
- Nobody else on the internet seems to have had this problem.
My conclusion is rapidly approaching 'wx.Python is broken...' but I
doubt it. Are there any other troubleshooting tips you guys can think
of?
Please make a runnable, small as possible, sample application that demonstrates the problem, and let us know the platform and wx version. MakingSampleApps - wxPyWiki
···
On 11/8/11 2:40 PM, Taylor wrote:
Hello All,
I've tried two things, both of which freeze my computer, to get a
selectable list out to a user's eyes, A ComboBox and a ListBox. Both
are causing freezes; ComboBox, on dropdown, and ListBox, on clicking
within the box. I've run out of ideas for troubleshooting... Details:
- I'm using relatively large lists (~200 items).
- I've left the select events un-bound, to see if it was one of my
methods causing the clog. This fixed nothing.
- Even if there are no other objects in the window, it still causes a
freeze. The hidden objects within the window are negligible.
- Calls to the boxes are basically: 'make list ; create listbox with
choices = list ; put listbox in sizer'. And that's it.
- Nobody else on the internet seems to have had this problem.
My conclusion is rapidly approaching 'wx.Python is broken...' but I
doubt it. Are there any other troubleshooting tips you guys can think
of?
Righto: I can't reproduce the freeze whilst trying to, unless it's on
my original window. I've narrowed the freeze itself to one of a few
objects. I'll make a reply to this thread once I figure out what
exactly is causing this, in case anyone else runs into my issue.
It looks like I've significantly narrowed down the root cause of this,
although I haven't quite reached a satisfactory solution:
My application is one which, at a given time, is likely to have more
than one panel as a child of the main window. One of the functions is
to switch between these Panels; similar to a wizard, but less one-
dimensional in its navigation. The functions for 'moving' from one
panel to another is actually to hide the previous panel and show the
next panel. The panel which breaks contains a GridBagSizer (containing
a set of static texts and a set of coloured panels) and three
ListBoxes, all within a BoxSizer.
I have managed to make the ListBox selectable by three means: 1)
Remove the coloured panels from the GridSizer. 2) Remove the
StaticTexts from the GridSizer. 3) Destroy the previous panel during
panel shifting. I'm not keen on using any of these three solutions
I suspect that the existence of previous panels in memory is
interfering with my breaking panel. Is this plausible? Does it make
any sense that removing independent objects would make the program run
smoothly? Any ideas on what else I can try to fix this?
The reason I was encountering this freeze was because, during the
application load, I was letting windows (the OS) try to rush the
application. (By putting the window into 'not responding' mode, after
it had taken ~10 seconds to load a panel). By rushing the application;
it did indeed load faster, by about 150%, but apparently caused this
bug.
Just curious: what kind of panel takes 10 seconds to load? In some of
my applications I am rendering millions of objects in multiple 3D VTK
windows through wxPython and I have never seen such a long loading
time.
The reason I was encountering this freeze was because, during the
application load, I was letting windows (the OS) try to rush the
application. (By putting the window into 'not responding' mode, after
it had taken ~10 seconds to load a panel). By rushing the application;
it did indeed load faster, by about 150%, but apparently caused this
bug.
