<Swing Dev> Review request for 6894632: Removing rows from a DefaultTableModel with a RowSorter deselectes last row
Semyon Sadetsky
semyon.sadetsky at oracle.com
Wed Apr 1 14:56:24 UTC 2015
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