JDK-4677999 : REGRESSION: Data not stored in TableModel when focus lost from JTable
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-05-01
  • Updated: 2002-08-01
  • Resolved: 2002-08-01
Related Reports
Duplicate :  
Relates :  
Description

Name: gm110360			Date: 05/01/2002


FULL PRODUCT VERSION :
java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
When the focus first enters the JTable (either by keyboard
or mouse) and data is entered into a SINGLE cell. When the
focus is then removed from the table (eg Clicking on a
button) the data is not set in the TableModel.

When focus is subsequently moved to the table again, data
entered and focus removed again, the data is stored.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Execute the sample code. (focus should begin on button1)
2. Click on any cell in the JTable and type a few characters
3. Click on the button1 to remove focus
--  Data is not stored in TableModel --
4. Click on any cell again and type some text
5. Click on button1 again to remove focus
-- This (and subsequent times) stores the data as expected -
-

EXPECTED VERSUS ACTUAL BEHAVIOR :
On first entering data into the JTable, the data should
have been stored in the TableModel when the focus was
removed like it does in subsequent attempts.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.table.*;
import java.awt.*;

public class Test extends JFrame
{
   public JTable table;
   public JScrollPane sp;
   public JButton button1 = new JButton("Button 1");
   
   public String a[] = new String[10];
   public String b[] = new String[10];
   
   public Test()
   {
      
      AbstractTableModel tableModel = new AbstractTableModel() {
          public int getColumnCount() { return 2; }
          public int getRowCount() { return 10; }
          public Object getValueAt(int row, int col) { return (col == 0 ? a
[row] : b[row]); }
          public void setValueAt(Object value, int row, int col) {
            if (col == 0)
               a[row] = (String)value;
            else
               b[row] = (String)value;
                }
          public boolean isCellEditable(int row, int col) { return true; }
          public String getColumnName(int col) { return "abcd"; }
          public Class getColumnClass(int col) { return String.class; }
      };
      
      table = new JTable(tableModel);
      sp = new JScrollPane(table);
      getContentPane().setLayout(new FlowLayout());
		getContentPane().add(button1);
		getContentPane().add(sp);
		
		setVisible(true);
		setSize(600,600);
		repaint();
	}
	
	public static void main(String args[])
	{
	   Test f = new Test();
	}
	
}
---------- END SOURCE ----------

Release Regression From : 1.3.1_03
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 139613) 
======================================================================

Comments
EVALUATION First, an important point needs to be clarified. In 1.3.0, the "appearance" is that an edit is committed to the model on focus lost. In fact, that is not the case. It remains visible in the editor but doesn't make it to the model. That being said, a fix was made in 1.4.0 to cancel an ongoing edit when the JTable loses focus. In some respects this is better since the model stays in synch with the view. However, a mistake was made and this "cancel" would only happen the first time the table lost focus. This is the behavior that the user is seeing now. In 1.4.1, we tried to fix things by making JTable cancel any edit on all focus losses. We were successful but developers didn't like the behavior. We have now moved things back to 1.3.0 behavior. Lastly, a property has been added to turn on "commit-or-cancel" behavior, the details of which are in 4709394. Closing as a duplicate of that bug. ###@###.### 2002-08-01
01-08-2002