Preserve JTable selection across TableModel change
Asked Answered
L

7

16

We're seeing JTable selection get cleared when we do a fireTableDataChanged() or fireTableRowsUpdated() from the TableModel.

Is this expected, or are we doing something wrong? I didn't see any property on the JTable (or other related classes) about clearing/preserving selection on model updates.

If this is default behavior, is there a good way to prevent this? Maybe some way to "lock" the selection before the update and unlock after?

The developer has been experimenting with saving the selection before the update and re-applying it. It's a little slow.

This is Java 1.4.2 on Windows XP, if that matters. We're limited to that version based on some vendor code we use.

Luedtke answered 31/10, 2008 at 16:59 Comment(0)
M
4

You need to preserve the selection and then re-apply it.

First of all you will need to get a list of all the selected cells.

Then when you re-load the JTable with the new data you need to programmatically re-apply those same selections.

The other point I want to make is, if the number or rows or columns in your table are increasing or decreasing after each table model reload, then please don't bother preserving the selection.

The user could have selected row 2 column 1 having a value say "Duck", before model updation. But after model updation that same data can now occur in row 4 column 1, and your original cell row 2 column 1 could have new data such as "Pig". Now if you forcibly set the selection to what it was before the model updation, this may not be what the user wanted.

So programmatically selecting cells could be a double edged sword. Don't do it, if you are not sure.

Mossgrown answered 1/11, 2008 at 19:53 Comment(0)
S
4

You can automatically preserve a table's selection if the STRUCTURE of that table hasn't changed (i.e. if you haven't add/removed any columns/rows) as follows.

If you've written your own implementation of TableModel, you can simply override the fireTableDataChanged() method:

@Override
public void fireTableDataChanged() {
    fireTableChanged(new TableModelEvent(this, //tableModel
        0, //firstRow
        getRowCount() - 1, //lastRow 
        TableModelEvent.ALL_COLUMNS, //column 
        TableModelEvent.UPDATE)); //changeType
}

and this should ensure that your selection is maintained provided that only the data and not the structure of the table has changed. The only difference between this, and what would be called if this method weren't overridden is that getRowCount() - 1 is passed for the lastRow argument instead of Integer.MAX_VALUE, the latter of which acts a signifier that not only has all the data in the table changed but that the number of rows may have as well.

Signpost answered 20/3, 2012 at 12:21 Comment(5)
beware: doing so might backfire - a dataChanged may include inserts/deletes. If that's the case, listeners might be severely misledShawannashawl
Wouldn't that be a structureChanged then?Signpost
no, a structureChanged is when the columns are changed along with the dataShawannashawl
You mean columns and/or rows right? And by inserts/deletes do you mean the addition of columns and/or rows or something else? Sorry guess I'm still a bit confused but it sounds like what you're saying here is really important for me to understandSignpost
yeah, the api doc of which event to fire isn't overly clear: to understand we have to read carefully those of both AbstractTableModel.fireXX methods and TableModelEvent ;-) A tableModel's structure == set of columns, so whenever a column is removed/inserted (or even moved) structureChanged must be fired. The insert/remove/update for single bounded ranges are obvious. A change which includes hard-to-express (in terms of single blocks) inserts/removes must fire a dataChangedShawannashawl
P
1

This is default behavior. If you call fireTableDataChanged() the entire table is rebuild from scratch as you set entirely new model. In this case the selection is, naturally, lost. If you call fireTableRowsUpdated() the selection is also cleared in general cases. The only way is to remember selection and then set this. Unfortunately there is no guarantee that the selection will be still valid. Be careful if restoring selection.

Popularize answered 2/11, 2008 at 12:26 Comment(0)
B
1

I had the same issue in an application. In my case the model in the table was a list of objects, where the object properties where mapped to columns. In that case, when the list was modified, I retrieved the selected index and stored the object that was selected before updating the list. After the list is modified and before the table is updated, I would calculate the position of the selected object. If it was still present after the modification, then I would set the selection to the new index.

Just setting the selected index in the table after the modification will not work, because the object may change position in the list.

As a side note, I found that working with GlazedLists makes life much easier when dealing with tables.

Benempt answered 7/11, 2008 at 8:26 Comment(0)
A
1

for reference, as @Swapnonil Mukherjee stated, this did the trick with a table with selectable rows:

// preserve selection calling fireTableDataChanged()
final int[] sel = table.getSelectedRows();

fireTableDataChanged();

for (int i=0; i<sel.length; i++)
    table.getSelectionModel().addSelectionInterval(sel[i], sel[i]);
Aposematic answered 25/8, 2015 at 10:58 Comment(0)
P
0

If I recall correctly, saving selection and re-applying it is what we have done too...

Piggy answered 31/10, 2008 at 17:10 Comment(0)
T
-1

I was facing same issue and when tried to search the reason I got this question but it seems a bug in Java SDK. https://bugs.java.com/bugdatabase/view_bug?bug_id=4276786

WORK AROUND

A temporary work-around is available. It should be removed once this bug is fixed as it's suitability has NOT been tested against fixed releases.

Use this subclass of JTable.

Note: This is for the MetalLookAndFeel. If using other look and feels, the inner FixedTableUI subclass will have to extend the TableUI subclass for that look and feel.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.table.*;
import javax.swing.event.*;
import javax.swing.plaf.basic.*;

public class FixedTable extends JTable {

  private boolean isControlDownInDrag;

  public FixedTable(TableModel model) {
      super(model);
      setUI(new FixedTableUI());
  }

  private class FixedTableUI extends BasicTableUI {
      private MouseInputHandler handler = new MouseInputHandler() {
          public void mouseDragged(MouseEvent e) {
              if (e.isControlDown()) {
                  isControlDownInDrag = true;
              }
              super.mouseDragged(e);
          }

          public void mousePressed(MouseEvent e) {
              isControlDownInDrag = false;
              super.mousePressed(e);
          }

          public void mouseReleased(MouseEvent e) {
              isControlDownInDrag = false;
              super.mouseReleased(e);
          }
      };

      protected MouseInputListener createMouseInputListener() {
          return handler;
      }
  }

  public void changeSelection(int rowIndex, int columnIndex, boolean toggle, boolean extend) {
      if (isControlDownInDrag) {
          ListSelectionModel rsm = getSelectionModel();
          ListSelectionModel csm = getColumnModel().getSelectionModel();

          int anchorRow = rsm.getAnchorSelectionIndex();
          int anchorCol = csm.getAnchorSelectionIndex();

          boolean anchorSelected = isCellSelected(anchorRow, anchorCol);

          if (anchorSelected) {
              rsm.addSelectionInterval(anchorRow, rowIndex);
              csm.addSelectionInterval(anchorCol, columnIndex);
          } else {
              rsm.removeSelectionInterval(anchorRow, rowIndex);
              csm.removeSelectionInterval(anchorCol, columnIndex);
          }

          if (getAutoscrolls()) {
              Rectangle cellRect = getCellRect(rowIndex, columnIndex, false);
              if (cellRect != null) {
                  scrollRectToVisible(cellRect);
              }
          }
      } else {
          super.changeSelection(rowIndex, columnIndex, toggle, extend);
      }
  }
}

Note Curtsey to http://bugs.sun.com

Tenstrike answered 9/8, 2013 at 8:55 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.