<Swing Dev> Review request for 6894632: Removing rows from a DefaultTableModel with a RowSorter deselectes last row

[Semyon Sadetsky]

Hi Sergey,

the ticket to correct the spec is created 
https://bugs.openjdk.java.net/browse/JDK-8076474

--Semyon


On 3/26/2015 2:35 AM, Sergey Bylokhov wrote:
> Hi, Semyon.
> There is a problem which we discussed offline already. This change fix 
> the problem described in the bug report, but it contradicts the 
> specification of this method, which state that tableChanged should 
> clears the selection if any. So the specification should be updated 
> also via ccc: in this CR if you have no plan to backport it to jdk8, 
> or in separate CR if you plan to backport it to jdk8.
>
> 06.03.15 15:30, Semyon Sadetsky wrote:
>> Hi Sergey,
>>
>> Good catch! Yes it should be inverted.
>> I fix that and added more extensive test scenarios to double check 
>> different table states.
>> Please review.
>> It's here:
>> http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/6894632/webrev.02/
>>
>> Thanks!
>> Semyon
>>
>> On 3/6/2015 1:26 AM, Sergey Bylokhov wrote:
>>> Hi, Semyon .
>>> Are you sure that this new if-statement is correct? it seems that it 
>>> should be opposite. No?
>>>
>>> On 04.03.2015 13:45, Alexander Scherbatiy wrote:
>>>> 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.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>