The fix looks good to me.
Thanks,
Alexandr.
On 3/4/2015 12:29 PM, Semyon Sadetsky wrote:
No, because it wouldn't be a valid state. The primary sort column is
always the first. If primary is unsorted then there are no more sorted
columns.
On 3/4/2015 11:54 AM, Alexander Scherbatiy wrote:
Is it possible that getSortKeys() methods returns some sort keys
where the first has unsorted sort order but others do not.
Thanks,
Alexandr.
On 3/2/2015 5:47 PM, Semyon Sadetsky wrote:
Hello,
Please review the fix:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/6894632/webrev.01/
for bug: https://bugs.openjdk.java.net/browse/JDK-6894632
The thing is the sorter logic uses its internal data structures to
restore selection when the table model has been changed.
For performance reason this internal data is created only upon the
table sort call. If sortable JTable is initialized with no sort
order specified the table sort is not executed and table remains
unsorted as JTable without sorting capability.
When the model of table in such state is changed the corresponding
event handler logic still called the sorter to transform selection.
But since the sorter internal cache was empty the transformation
failed in cases when the selection index exceeds the new table rows
count.
Now with the fix the sorter is updated with table model change event
only if the table is really sorted.
