tags:

views:

1496

answers:

4

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.

A: 

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

PhiLho
+3  A: 

Hi,

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. Take a look at this example

Getting the Selected Cells in a JTable Component

Then when you re-load the JTable with the new data you need to programmatically re-apply those same selections. This is how you do that

Programmatically Making Selections in a JTable Component

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.

swapnonil
A: 

This is default behavior. If you call fireTableDataChanged() the entire tabla 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 guaranteed then the selection will be still valid. Be careful if restoring selection.

Rastislav Komara
A: 

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.

Mario Ortegón