I would like to request a change to
wx.lib.scrolledpanel.py (2.8.11.0) that adds a new keyword parameter, “scrollIntoView”, to the SetupScrolling method, see
attached patch. The value would be True by default, following existing
behaviour but, if set False, would prevent any child Window that
receives focus from scrolling the panel. This currently happens
automatically if the child window is only partially in view and it
scrolls the panel up and/or to the right to bring the child window
fully into view if possible.
The problem that this behaviour causes can be seen in the attached,
stand-alone example. The panel contains a list of words, displayed in
rows, that the user can click on. Each clicked word is returned to the
caller. A vertical panel scrollbar appears when the list is
sufficiently long. The panel is resizeable so it is unlikely that its
height displays an exact number of rows. So if any word on the bottom
row is clicked, the left-click-down causes a child window focus event
that, by default, scrolls the panel display up by one row (as it so
happens). So the left-click-up that selects a word actually returns one
from the next row down instead of the one intended. It’s actually
easier to see what’s happening in the example than it is to explain it Regards,
David Hughes
Forestfield Software
Working around this issue wouldn't be too hard, but your patch is a good idea regardless. I've just committed it to both branches.
Thanks!
···
On 6/8/10 7:38 AM, David Hughes wrote:
I would like to request a change to wx.lib.scrolledpanel.py (2.8.11.0)
that adds a new keyword parameter, "scrollIntoView", to the
SetupScrolling method, see attached patch. The value would be True by
default, following existing behaviour but, if set False, would prevent
any child Window that receives focus from scrolling the panel. This
currently happens automatically if the child window is only partially in
view and it scrolls the panel up and/or to the right to bring the child
window fully into view if possible.
The problem that this behaviour causes can be seen in the attached,
stand-alone example. The panel contains a list of words, displayed in
rows, that the user can click on. Each clicked word is returned to the
caller. A vertical panel scrollbar appears when the list is sufficiently
long. The panel is resizeable so it is unlikely that its height displays
an exact number of rows. So if any word on the bottom row is clicked,
the left-click-down causes a child window focus event that, by default,
scrolls the panel display up by one row (as it so happens). So the
left-click-up that selects a word actually returns one from the next row
down instead of the one intended. It's actually easier to see what's
happening in the example than it is to explain it