Drawing a rectangle to a list control, part 2

I am getting hopelessly confused. I thought that I had this widget working
perfectly, but I just discovered a problem with the scrollwin_thumbtrack
event -- that is, the user is dragging the thumb in the scrollbar. When I
scroll the shaded item off the top of the screen and then return it to the
top of the screen, I get a message from my paint handler that it is going
to repair a rectangle at the top of the screen in the appropriate location.
If I continue to drag the thumb, the item moves to some other portion of
the list control. When I then release the thumb, the redraw occurs not
where my paint handler said it would, but where the item is located.
That's good, though somewhat mysterious. It seems as if there are actual
coordinates (coordinates in the visible window) and virtual coordinates
(coordinates in the virtual window that we are viewing through the window),
and the message I get from my paint handler is giving me virtual
coordinates (which don't change when I continue to drag the thumb). So
far, so good.

Now consider what happens when I perform the same experiment, but drag the
item off the bottom of the screen. As before, when the item returns to the
screen, I get a message that the repair will take place at the position
where the item is first visible. I continue to drag the thumb so that the
item is positioned somewhere higher in the screen and then release the
thumb. The repaint occurs exactly where my handler said it would take
place, at the bottom of the screen, not at the final position of the item.
That's bad. It seems as if the message I get from my handler in this case
is in actual coordinates, which are incorrect after the item moves to
different actual coordinates. Could this be a bug? I don't see a
rationale for having different behavior depending on whether the item moves
out of view at the top of the list control or the bottom.

···

--
Jeffrey Barish

Jeffrey Barish wrote:

It seems as if the message I get from my handler in this case
is in actual coordinates, which are incorrect after the item moves to
different actual coordinates. Could this be a bug?

Could be. It could also be something like the events happening in a little different order when scrolling in the different directions.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!