Comments on: Swing Puzzler #1 http://www.pushing-pixels.org/?p=1636 Leaving no pixel behind Wed, 01 Sep 2010 04:26:41 -0700 hourly 1 http://wordpress.org/?v=3.0.1 By: Java desktop links of the week, February 21 | Jonathan Giles http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11350 Java desktop links of the week, February 21 | Jonathan Giles Sun, 21 Feb 2010 20:42:05 +0000 http://www.pushing-pixels.org/?p=1636#comment-11350 [...] Grouchnikov posted a Swing Puzzler asking what you expect following a short snippet of code. I share his sentiment about not liking [...] [...] Grouchnikov posted a Swing Puzzler asking what you expect following a short snippet of code. I share his sentiment about not liking [...]

]]> By: Thierry Lefort http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11311 Thierry Lefort Tue, 16 Feb 2010 12:37:31 +0000 http://www.pushing-pixels.org/?p=1636#comment-11311 Great puzzler ! Reminded me from the good old days, Who said Swing backward compatibility was sometimes a real pain ;-) Nice answer by Jeanette, as always ! Great puzzler !

Reminded me from the good old days, Who said Swing backward compatibility was sometimes a real pain ;-)

Nice answer by Jeanette, as always !

]]> By: Jeanette Winzenburg http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11310 Jeanette Winzenburg Tue, 16 Feb 2010 12:00:14 +0000 http://www.pushing-pixels.org/?p=1636#comment-11310 Doesn't matter what the new model is (as Aekold already pointed out) - the base problem is that "during self-cleanup" of the table its state is more or less indeterminate. That's hard to overcome, whatever the sequence of updating the sorter/selection/ internals are. In the ol' SwingX sorting we forced the selectionModel to adjusting while processing any tableEvent ... note to myself: should do so again, at least on structureChagned ;-) Cheers Jeanette Doesn’t matter what the new model is (as Aekold already pointed out) – the base problem is that “during self-cleanup” of the table its state is more or less indeterminate. That’s hard to overcome, whatever the sequence of updating the sorter/selection/ internals are. In the ol’ SwingX sorting we forced the selectionModel to adjusting while processing any tableEvent … note to myself: should do so again, at least on structureChagned ;-)

Cheers
Jeanette

]]> By: Ruben http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11309 Ruben Tue, 16 Feb 2010 10:01:57 +0000 http://www.pushing-pixels.org/?p=1636#comment-11309 The answer is: "Table: 1, model: 0" It is due to the line that says: table.setAutoCreateRowSorter(true); This line creates a TableModel that wraps the current TableModel in the table (RowSorter). Then, when you call table.getRowCount(), the table returns the row count returned by RowSorter instead of the DefaultTableModel. When you reset the TableModel, you are changing only the TableModel, but the table still has a RowSorter. Thats why table.getRowCount() returns a different value of table.getModel().getRowCount(). If you comment the line table.setAutoCreateRowSorter(true); the last line printed will be: "Table: 0, model: 0" as we expected. The answer is: “Table: 1, model: 0″
It is due to the line that says: table.setAutoCreateRowSorter(true);
This line creates a TableModel that wraps the current TableModel in the table (RowSorter). Then, when you call table.getRowCount(), the table returns the row count returned by RowSorter instead of the DefaultTableModel.
When you reset the TableModel, you are changing only the TableModel, but the table still has a RowSorter. Thats why table.getRowCount() returns a different value of table.getModel().getRowCount().
If you comment the line table.setAutoCreateRowSorter(true); the last line printed will be: “Table: 0, model: 0″ as we expected.

]]> By: Aekold http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11308 Aekold Tue, 16 Feb 2010 10:01:01 +0000 http://www.pushing-pixels.org/?p=1636#comment-11308 It gets obvious when looking at JTable's source code. JTable.getRowCount() takes count from RowSorter, but replacing RowSorter is very last part in setModel() method. Of course it is not good practice at all, and as for me it would be better to remove all those methods from JTable class to make everyone use MVC without compromises, but Java's backward compatibility trap will never allow it. It gets obvious when looking at JTable’s source code. JTable.getRowCount() takes count from RowSorter, but replacing RowSorter is very last part in setModel() method. Of course it is not good practice at all, and as for me it would be better to remove all those methods from JTable class to make everyone use MVC without compromises, but Java’s backward compatibility trap will never allow it.

]]> By: Panos http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11306 Panos Tue, 16 Feb 2010 08:33:01 +0000 http://www.pushing-pixels.org/?p=1636#comment-11306 Should it not be 0 & 0? If you reset the table model to a DefautlTableModel then it should be 0 & 0, according to the javadocs "Constructs a default DefaultTableModel which is a table of zero columns and zero rows." and (for table.getRowCount()) "Returns the number of rows in this table's model. " Should it not be 0 & 0? If you reset the table model to a DefautlTableModel then it should be 0 & 0, according to the javadocs

“Constructs a default DefaultTableModel which is a table of zero columns and zero rows.”

and (for table.getRowCount())

“Returns the number of rows in this table’s model. “

]]> By: Kirill Grouchnikov http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11304 Kirill Grouchnikov Tue, 16 Feb 2010 07:23:48 +0000 http://www.pushing-pixels.org/?p=1636#comment-11304 Adam, Did you run the code with your suggested change (explicitly passing parameters to the new instance of DefaultTableModel)? I don't see any change in the results. Thanks Kirill Adam,

Did you run the code with your suggested change (explicitly passing parameters to the new instance of DefaultTableModel)? I don’t see any change in the results.

Thanks
Kirill

]]> By: adam http://www.pushing-pixels.org/?p=1636&cpage=1#comment-11301 adam Tue, 16 Feb 2010 07:01:43 +0000 http://www.pushing-pixels.org/?p=1636#comment-11301 It will be Table: 1, model: 0 The reason is because when you add the new DefaultTableModel you do not specify the an of the data (rows or columns) for the new TableModel and thus it is constructed with zero rows and zero columns and thus remembers the previous number of rows from a cached value in the JTable.getRowCount() I believe. This is illustrated by adding a button to add new rows of data then selecting all the rows and then adding a new TableModel. The output will be Table: , model: 0. This can be solved by changing the code to "new DefaultTableModel(new Object[0][], new Object[] { "Column", "Names" })" instead of the default constructor. It will be Table: 1, model: 0
The reason is because when you add the new DefaultTableModel you do not specify the an of the data (rows or columns) for the new TableModel and thus it is constructed with zero rows and zero columns and thus remembers the previous number of rows from a cached value in the JTable.getRowCount() I believe. This is illustrated by adding a button to add new rows of data then selecting all the rows and then adding a new TableModel. The output will be Table: , model: 0. This can be solved by changing the code to “new DefaultTableModel(new Object[0][], new Object[] { “Column”, “Names” })” instead of the default constructor.

]]>