Community
Participate
Working Groups
Build Identifier: 3.7.0.2011-Jun 2011 PROBLEM DESCRIPTION: Assume a table with a bunch of rows and an existing set of selected rows. When the user presses the "up" or "down" key, the selection is cleared and the row above or below the last selected row is now selected. This does not work, when the selection was not made by the user (mouse / keyboard) but manually in the code by calling "table.selectRow(index)" (e.g. during the execution of a button action). The new selection _looks_ correct, but when the "up" or "down" key is pressed, the table behaves as if the old selection would was still present. EVALUATION: The problem is located in the class SwingScoutTable, presumably in the method setSelectionFromScout(). This method calculates which selection rows are new and which rows should be removed from the seleciton, and then calls the methods ListSelectionModel.addSelectionInterval() and ListSelectionModel.removeSelectionInterval(), respectively. Those calls seem to leave the anchor and lead selection indexes untouched. Because those two values are consulted when the user presses the "up" or "down" key, the resulting selection is wrong. PROPOSED SOLUTION: Anchor and lead selection index have to be updated as well. The attached patch basically adds such a functionality (could probably be improved). Reproducible: Always
Created attachment 200977 [details] Proposed Patch
Thanks for the patch. But how do you think this could be improved? Do you have a hint?
No, I just usually try to avoid variables that are considered "uninitialized" when being negative (because in fact, they _are_ initialized). For that particular method however, this seems to be the best solution.
Applied patch to 3.8 branch. Will be merged with 3.9 Git repo. Migration: none
fixed flags and target milestone
to be verified.
Bug closed, shipped with 3.9.0 (Kepler)