Name: skT45625 Date: 04/17/2000


java version "1.3.0rc2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc2-Y)
Java HotSpot(TM) Client VM (build 1.3.0rc2-Y, mixed mode)

Run TableExample4 in the demo/TableExample directory. double click on a cell and
modify the text in the cell. While the cell is still in the editing mode. click
a column header cell or resize a column. The newly entered data will be gone.
(Review ID: 103784)
======================================================================
Contribution provided by java.net member leouser:


A DESCRIPTION OF THE FIX :
BUG ID: 4330950 lost newly entered data in the cell when resizing column width.
FILES AFFECTED: javax.swing.JTable
JDK VERSION
jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin

Discusion(embeded in test case as well):
/**
 * BUG ID: 4330950 lost newly entered data in the cell when resizing column width.
 * The problem is that one size does not fit all. There is alot of complaining
 * in the bug report about what happens. The problem in defining what happens
 * one way is suddenly there is a group of people who are left out. To try
 * and make the excluded ones happy we come to JTable.ColumnEditorBehavior.
 * ColumnEditorBehavior is an enum that currently defines 3 behaviors that
 * make sense when faced with column manipulation: revert, save and continue.
 * Im not sure whatever behaviors people need: if these don't cut the muster
 * maybe a better solution would be to allow a pluggable behavior defining
 * class. But with that people are going to complain that they have to define
 * a class to get what they want. To answer these folks we may add another
 * option: CUSTOM. When CUSTOM would be used the JTable would look to a custom
 * handler to deal with what should happen. If this solution is taken we
 * may want to wait to add that mechanism. It may prove to be an unneeded tool.
 * WHY ARE MOVING COLUMNS WITH SAVE AND CONTINUE THE SAME?
 * Well, because they both enable the same behavior. Once you move a column
 * you can start editing again by typing. I guess you could complain that
 * visually they should be distinct... . Ideally it would be great that
 * clicking on the header didn't knock out the editing session for CONTINUE
 * but there is not a good way to determine when editing should stop during
 * movement. If you use the index measurement from != to the value stored
 * in the cell goes to the swapped column/row! If we try to do it based off
 * of changing values in getCellRect, this doesn't help either... I saw
 * the same value returned over and over until the column moved. At least
 * we can differentiate on the resizing behavior.
 *
 * ANTI-RATIONALE:
 * 1. Adds 2 new public methods and an enum to the interface of JTable. Could
 * break existing clients that are expecting this behavior. This is why
 * I set the default behavior to REVERT.
 *
 * Testing Strategy:
 * 1. Create 3 JFrames with JTables in them. Each JTable has one of the different
 * behaviors. Play with the behaviors to see how they differ. See if they
 * break anything.
 * We are not doing a tradition JUnit style test here because you have to
 * see the results of the interaction. I guess we could programmatically
 * try to move things around but what we want is a test of behavior based off
 * of user interaction.
 *
 * FILES AFFECTED: javax.swing.JTable
 * JDK VERSION
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 20, 2006
 */

UNIFIED DIFF:
--- /home/nstuff/java6/jdk1.6.0/javax/swing/JTable.java Thu Dec 15 02:17:37 2005
+++ /home/javarefs/javax/swing/JTable.java Fri Jan 20 15:00:49 2006
@@ -231,6 +231,35 @@
         FIT_WIDTH
     }
 
+ /**
+ * Defines the behavior of the editor when columns
+ * are manipulated: resized, clicked on or moved.
+ *
+ * @see #getColumnEditorBehavior
+ * @see #setColumnEditorBehavior
+ */
+ public enum ColumnEditorBehavior{
+
+ /**
+ * When the column is resized or clicked on,
+ * revert to the starting value and stop editing.
+ */
+ REVERT,
+
+ /**
+ * When the column is resized, moved or clicked on,
+ * save the editors contents and stop editing.
+ */
+ SAVE,
+
+ /**
+ * When the column is resized, continue with the editing.
+ * If moved or clicked on, act as {@code SAVE}.
+ */
+ CONTINUE
+
+ }
+
 
 //
 // Instance Variables
@@ -331,6 +360,9 @@
     /** The background color of selected cells. */
     protected Color selectionBackground;
 
+ /** The {@code ColumnEditorBehavior} property. */
+ protected ColumnEditorBehavior ceBehavior = ColumnEditorBehavior.REVERT;
+
 //
 // Private state
 //
@@ -2598,6 +2630,13 @@
     }
 
     /**
+ * Returns the {@code ColumnEditorBehavior} property.
+ *
+ * @return the {@code ColumnEditorBehavior} enum
+ */
+ public ColumnEditorBehavior getColumnEditorBehavior(){ return ceBehavior; }
+
+ /**
      * Returns the name of the column appearing in the view at
      * column position <code>column</code>.
      *
@@ -3671,6 +3710,15 @@
     }
 
     /**
+ * Sets the {@code ColumnEditorBehavior} property.
+ *
+ * @param ceb the new {@code ColumnEditorBehavior}.
+ */
+ public void setColumnEditorBehavior(ColumnEditorBehavior ceb){
+ ceBehavior = ceb;
+ }
+
+ /**
      * Returns the <code>TableColumnModel</code> that contains all column information
      * of this table.
      *
@@ -4503,7 +4551,11 @@
     public void columnMoved(TableColumnModelEvent e) {
         // If I'm currently editing, then I should stop editing
         if (isEditing()) {
- removeEditor();
+ ColumnEditorBehavior ceb = getColumnEditorBehavior();
+ if(ceb == ColumnEditorBehavior.REVERT)
+ removeEditor();
+ else
+ cellEditor.stopCellEditing();
         }
         repaint();
     }
@@ -4520,9 +4572,7 @@
      * @see TableColumnModelListener
      */
     public void columnMarginChanged(ChangeEvent e) {
- if (isEditing()) {
- removeEditor();
- }
+ processCEBehavior();
  TableColumn resizingColumn = getResizingColumn();
  // Need to do this here, before the parent's
  // layout manager calls getPreferredSize().
@@ -4530,6 +4580,23 @@
  resizingColumn.setPreferredWidth(resizingColumn.getWidth());
  }
  resizeAndRepaint();
+ }
+
+ private void processCEBehavior(){
+ ColumnEditorBehavior ceb = getColumnEditorBehavior();
+ if(isEditing()){
+ switch(ceb){
+ case REVERT:
+ removeEditor();
+ break;
+ case SAVE:
+ if(cellEditor != null)
+ cellEditor.stopCellEditing();
+ break;
+ case CONTINUE:
+ break;
+ }
+ }
     }
 
     private int limit(int i, int a, int b) {


JUnit TESTCASE :
import javax.swing.*;
import java.awt.*;

/**
 * BUG ID: 4330950 lost newly entered data in the cell when resizing column width.
 * The problem is that one size does not fit all. There is alot of complaining
 * in the bug report about what happens. The problem in defining what happens
 * one way is suddenly there is a group of people who are left out. To try
 * and make the excluded ones happy we come to JTable.ColumnEditorBehavior.
 * ColumnEditorBehavior is an enum that currently defines 3 behaviors that
 * make sense when faced with column manipulation: revert, save and continue.
 * Im not sure whatever behaviors people need: if these don't cut the muster
 * maybe a better solution would be to allow a pluggable behavior defining
 * class. But with that people are going to complain that they have to define
 * a class to get what they want. To answer these folks we may add another
 * option: CUSTOM. When CUSTOM would be used the JTable would look to a custom
 * handler to deal with what should happen. If this solution is taken we
 * may want to wait to add that mechanism. It may prove to be an unneeded tool.
 * WHY ARE MOVING COLUMNS WITH SAVE AND CONTINUE THE SAME?
 * Well, because they both enable the same behavior. Once you move a column
 * you can start editing again by typing. I guess you could complain that
 * visually they should be distinct... . Ideally it would be great that
 * clicking on the header didn't knock out the editing session for CONTINUE
 * but there is not a good way to determine when editing should stop during
 * movement. If you use the index measurement from != to the value stored
 * in the cell goes to the swapped column/row! If we try to do it based off
 * of changing values in getCellRect, this doesn't help either... I saw
 * the same value returned over and over until the column moved. At least
 * we can differentiate on the resizing behavior.
 *
 * ANTI-RATIONALE:
 * 1. Adds 2 new public methods and an enum to the interface of JTable. Could
 * break existing clients that are expecting this behavior. This is why
 * I set the default behavior to REVERT.
 *
 * Testing Strategy:
 * 1. Create 3 JFrames with JTables in them. Each JTable has one of the different
 * behaviors. Play with the behaviors to see how they differ. See if they
 * break anything.
 * We are not doing a tradition JUnit style test here because you have to
 * see the results of the interaction. I guess we could programmatically
 * try to move things around but what we want is a test of behavior based off
 * of user interaction.
 *
 * FILES AFFECTED: javax.swing.JTable
 * JDK VERSION
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 20, 2006
 */
public class TestJTLostData{


    public static class GUIBuilder implements Runnable{

public void run(){

JFrame jf1 = createJTable(JTable.ColumnEditorBehavior.REVERT,0,0);
Dimension b1 = jf1.getSize();
int x2 = 0 + b1.width;
int y2 = 0 + b1.height;
JFrame jf2 = createJTable(JTable.ColumnEditorBehavior.SAVE,x2,0);
JFrame jf3 = createJTable(JTable.ColumnEditorBehavior.CONTINUE,0,y2);


}

public JFrame createJTable(JTable.ColumnEditorBehavior ceb, int x, int y){

JFrame jf = new JFrame();
jf.setTitle(ceb.toString());
Object[][] data = new Object[10][10];
Object[] cnames = new Object[10];
for(int i = 0; i < 10; i++){
cnames[i] = String.valueOf(i);
for(int i2 = 0; i2 < 10; i2++)
data[i][i2] = i2;
}

JTable jt = new JTable(data, cnames);
jt.setColumnEditorBehavior(ceb);
JScrollPane jsp = new JScrollPane(jt);
jf.add(jsp);
jf.pack();
jf.setLocation(x,y);
jf.setVisible(true);
return jf;
}

    }



    public static void main(String ... args){

        SwingUtilities.invokeLater(new GUIBuilder());

    }


}


FIX FOR BUG NUMBER:
4330950