However in the newest version of my program it has stopped
drawing on Linux and Mac (everything is fine on Windows).
The contents don't draw unless you resize the frame. Clicking
on items has no effect (it doesn't select them). If I press
the down arrow then it whites out the entries that would be
selected. I have attached a screenshot showing the result
of that.
It works fine in LC_ICON mode.
Does anyone have any ideas what could cause this or further
pointers on where to investigate?
The things I changed from my older version where, turning off
single selection (ie allowing for multiple selection), putting
in Freeze/Thaw, moving this derived class to a seperate file.
I even tried a hack job and undid all those changes. I have
pored over diffs and cannot see a single wx call that is
different or in a different order.
am I right when I suppose that everything works correctly after the
frame has been resized? Maybe the listbox doesn't have the correct size
at first? That would indicate a problem with the layout (rather than the
listbox itself).
What would help is if you could provide an example which shows the
problem in a single file. I know this is a tedious job, but on the other
hand chances are that this process may already reveal the source of the
problem
Markus
···
Am Fre, den 02.01.2004 schrieb Roger Binns um 10:19:
I have a list control in my program. This is a screenshot:
However in the newest version of my program it has stopped
drawing on Linux and Mac (everything is fine on Windows).
The contents don't draw unless you resize the frame. Clicking
on items has no effect (it doesn't select them). If I press
the down arrow then it whites out the entries that would be
selected. I have attached a screenshot showing the result
of that.
It works fine in LC_ICON mode.
Does anyone have any ideas what could cause this or further
pointers on where to investigate?
The things I changed from my older version where, turning off
single selection (ie allowing for multiple selection), putting
in Freeze/Thaw, moving this derived class to a seperate file.
I even tried a hack job and undid all those changes. I have
pored over diffs and cannot see a single wx call that is
different or in a different order.
However in the newest version of my program it has stopped
drawing on Linux and Mac (everything is fine on Windows).
The contents don't draw unless you resize the frame. Clicking
on items has no effect (it doesn't select them). If I press
the down arrow then it whites out the entries that would be
selected.
The not-drawing-until-resized symptom can usually be solved by adding a Layout call at an appropriate place. But the rest of the description makes me think it is something else, such as the listctrl's internal data structures getting confused.
IIRC, you need to *not* add new items in the same event hander that you call DeleteAllItems from because part of the cleanup does not happen until later. Try repopulating the list in another function invoked via wx.CallAfter.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
am I right when I suppose that everything works correctly after the
frame has been resized?
No. It doesn't draw anything (except the column headers) until
the resize happens. Once resized the contents are drawn. However
you still can't select any of them via mouse clicks, and pressing down
arrow resulted in the screenshot you saw (items not redrawn).
What would help is if you could provide an example which shows the
problem in a single file. I know this is a tedious job, but on the other
hand chances are that this process may already reveal the source of the
problem
ListCtrl obviously already works, and the code I have has no issue
on Windows. There is something somewhere that makes it misbehave
on Linux and Mac. There is far too much code and far too many
widgets to try and reproduce it outside my codebase.
The only thing I can think of is that it is some subtle issue with
one of the other notebook pages confusing the list somehow. Or
maybe some artifact of having a splashscreen, or something wierd
like that.
IIRC, you need to *not* add new items in the same event hander that you
call DeleteAllItems from because part of the cleanup does not happen
until later. Try repopulating the list in another function invoked via
wx.CallAfter.
I removed the call to DeleteAllItems and that made no difference. I
also tried the list population from wxCallAfter.
About the only other thing I can think of is that you shouldn't
mix "from wxPython.wx import *" and "import wx" in the same
program (things certainly go horribly wrong if you mix them in
the same module).
My choices are to either revert everything to the former or
convert everything to the latter.
Has anyone done a non-trivial program entirely in the "import wx"
style?
IIRC, you need to *not* add new items in the same event hander that you
call DeleteAllItems from because part of the cleanup does not happen
until later. Try repopulating the list in another function invoked via
wx.CallAfter.
I removed the call to DeleteAllItems and that made no difference. I
also tried the list population from wxCallAfter.
Please reduce it to a small-as-possible runnable sample that shows the problem and I'll take a look at it.
About the only other thing I can think of is that you shouldn't
mix "from wxPython.wx import *" and "import wx" in the same
program (things certainly go horribly wrong if you mix them in
the same module).
Mixing import types in different modules should have no effect like this on the wxListCtrl. The names from the two namespaces are references to the same class (or whatever) objects. IOW, "wxListCtrl is wx.ListCtrl" should evaluate to True.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Pick 0.7-test1. Accept the defaults for the setting dialog that appears.
Drag and drop files with an extension of .mid into the ringer pane. (They
don't actually have to be midi files - they just need that exception).
The Windows version will be fine. Linux and Mac will have the non-redrawing
until you resize and non-responsiveness to clicks.
My next plan is to move to using the virtual version of listctrl.
That will result in some of the code being significantly more
efficient.
If that doesn't fix it, I guess I am condemned to writing my own control.
