The functionality/implementation might not be to Greg's liking, but a
similar solution would be nice to get in there :)
-- Edvin
Den 15.05.2011 16:24, skrev Andrei Pozolotin:
Edvin: great! thank you. (I hope Greg applies it soon) Andrei.
-------- Original Message --------
Subject: Re: BUG: ListView selection with keys
From: Edvin Syse <[email protected]>
To: [email protected]
Date: Sun 15 May 2011 05:23:47 AM CDT
Here's a patch against trunk that fixes the problem :)
-- Edvin
Den 15.05.2011 09:28, skrev Edvin Syse:
When reading the source code of TerraListViewSkin, it looks like this is
indeed the case. It should be a simple fix, though...
Den 15.05.2011 09:11, skrev Edvin Syse:
Hm.. actually, you are right.. I get the same behavior as you describe.
Even when releasing shift, pressing up arrow doesn't release the
selection. It kind of looks like the "cursor" is on the first row,
because if you select let's say three elements in the middle of the
list
with shift+down, releasing shift and pressing up arrow will select the
element at the beginning of the list. But again, then pressing down
arrow should fix the problem in your example, but it doesn't...
-- Edvin
Den 15.05.2011 09:06, skrev Edvin Syse:
I think you might be confused by the behavior of using arrow keys
while
holding down shift. When shift is pressed and you press the down
arrow,
the next element after the current selection is added to the
selection.
If you press the up arrow, the element in front of the current
selection
range is selected. Hence, when all the elements are selected, pressing
up or down is not supposed to change anything. If you release
shift, the
selection changes (to one element), right?
-- Edvin
Den 15.05.2011 01:46, skrev Andrei Pozolotin:
BUG: ListView selection with keys
1) if you take this example
http://pivot.apache.org/tutorials/lists.html
2) select with mouse first item
3) then with keys: shift + down continue select until all list items
are
selected
4) now ListView no longer responds to key strokes
this is on 64 bit ubuntu 10.04 and jdk 1.6.0 _25
verified same bug in current trunk
