<Swing Dev> Review request for 6894632: Removing rows from a DefaultTableModel with a RowSorter deselectes last row
Alexander Scherbatiy
alexandr.scherbatiy at oracle.com
Fri Apr 3 12:51:54 UTC 2015
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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
More information about the swing-dev
mailing list