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

[Alexander Scherbatiy]

  The fix looks good to me.

  Thanks,
  Alexandr.

On 4/1/2015 5:56 PM, Semyon Sadetsky wrote:
> 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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>