Ultimately, the table model controls which cells, if any, of a table are editable. There are two TableModel methods that work together to control cell editability:

public boolean isCellEditable (int row, int column);
public void setValueAt (Object value, int row, int column);

When the user tries to change the value in a table cell (by means that you'll see later), the JTable user interface (UI) class calls the JTable isCellEditable method, passing it the cell's row and column number. If this method returns true, an appropriate editor is assigned to the cell and the user is allowed to change the value displayed in the cell. When the user has updated the cell, the new value is stored in the model by passing it to the setValueAt method, which is also given the cell's row and column number, together with the new value in the form of an Object. If isCellEditable returns false, the data cannot be edited and the user won't be able to type anything into the cell.

All of the examples you have seen so far have used the CurrencyTableModel shown in Listing 7-1, which didn't directly implement either isCellEditable or setValueAt. Instead, it inherited these methods from AbstractTableModel, which implements them as follows:

public boolean isCellEditable (int row, int column) {
   return false;
}
public void setValueAt (Object value, int row, int column) {
}

As implemented here, the isCellEditable method ensures that none of the table's cells can have their values changed, which is why all the tables in the previous chapter were not editable. When is CellEditable returns false for a cell, the table will not attempt to change the cell's value, so the default implementation of setValueAt just does nothing because, of course, it will never be called.

To make the CurrencyTableModel editable, suitable implementations of is CellEditable and setValueAt need to be added. Because CurrencyTableModel is useful as a read-only currency model, instead of changing it, the new methods will be implemented in a derived class called EditableCurrencyTableModel, the implementation of which is shown in Listing 7-1.

package AdvancedSwing.Chapter7;

import javax.swing.*;
import AdvancedSwing.Chapters6.*;

// An editable version of the currency table model
public class EditableCurrencyTableModel
                             extends CurrencyTableModel {
   public boolean isCellEditable (int row, int column) {
      return column == OLD_RATE_COLUMN ||
                        column == NEW_RATE_COLUMN;
   }

   public void setValueAt (Object value, int row, int column) {
   try {
         if (column == OLD_RATE_COLUMN ||
                        column == NEW_RATE_COLUMN) {
            Double newObjectValue; // New value as an Object
            double newValue; // double, for validity checking
            if (value instanceof Number) {
               // Convert Number to Double
               newValue = ((Number)value).doubleValue();
               newObjectValue = new Double(newValue);
            } else if (value instanceof String) {
               // Convert a String to a Double
               newObjectValue = new Double ((String)value);
               newValue = newObjectValue.doubleValue();
            } else {
               // Unrecognized - ignore
               return;
            }

            if (newValue > (double)0.0) {
               // Store new value, but reject zero or
               // negative values
               data [row] [column] = newObjectValue;
               data [row] [DIFF_COLUMN] =
new Double(((Double) data [row] [NEW_RATE_COLUMN]). doubleValue()
        - ((Double) data [row] [OLD_RATE_COLUMN]). doubleValue ());

               fireTableRowsUpdated (row, row);
            }
         }
      } catch (NumberFormatException e) {
         // Ignore a badly formatted number
      }
   }
}

As you can see, this class inherits most of its behavior from the existing CurrencyTableModel, as well as the initial currency values. The isCellEditable method is very simple: The editable version of the currency table will allow only today's or yesterday's exchange rates to be edited. Obviously, it makes no sense to allow the user to edit the difference between the two rates, while changing the currency name really implies the need to change all the values in the affected row, which is really a delete operation followed by the insertion of a new row, rather than an edit. These constraints are applied by arranging for isCellEditable to return true if, and only if, the cell being edited is in column 1 or 2, which were symbolically defined (by CurrencyTableModel) as OLD_RATE_COLUMN and NEW_RATE_COLUMN respectively. In this case, the decision as to whether a cell's contents can be modified is based entirely on which column it is in, but you can, if you need to, control editability on a cell-by-cell basis by using the row number as well as the column index.

The setValueAt method is slightly more complex. This method is given the new value (as an object) and the row and column index of the cell to be updated. In terms of the actual implementation of the CurrencyTable- Model, the new value needs to be assigned to the element data [row] [column] of the two-dimensional array that holds the data. There are, however, a few other things that need to be taken into account.

First, setvalueAt checks again that the cell to be changed is in columns 1 or 2. Of course, this repeats the same test made by isCellEditable and it may appear to be redundant. In terms of direct table editing, this check is, indeed, superfluous because the table will never attempt to update a cell for which isCellEditable returns false. However, other software can get direct access to the TableModel by calling the JTable getModel method and attempt to modify parts of the data that should be read-only. This check prevents such unauthorized access.

Next, the actual value needs to be stored in the table model. The value argument to setvalueAt is defined as an Object, so exactly what is its actual data type? As you'll see in the next section, the type of the value passed to setValueAt depends on the editor being used to modify the table. Ideally, because the table model holds Doubles, the editor would supply the new value as a Double (or at least as a Number). However, none of the editors installed in the table by default do this— in fact, the editor that would be used for both of the editable columns in this table supplies the modified value as a string.

The implementation of setvalueAt used here accepts either a string or a Number as the new value. If the value is supplied as a Number, it is converted directly to a Double by extracting the double value from the Number and then passing it to the constructor of Double. When a string is supplied, it is passed directly to the Double constructor that accepts a String argument and the result is stored in the data array.

Once the new value has been stored, there is one final item of business to be attended to. The last column of the table always contains the difference between the old and new currency rates, so when either of these values is changed, it is necessary to calculate a new value for this column. The same code is used to perform this calculation as that used in the constructor of CurrencyTableModel shown in Listing 7-1 in the previous chapter. Once the new difference has been stored, the table is self-consistent again.

Once the editor has completed its job and setvalueAt has been called, the table will update the cell with the new value automatically, as you'll see shortly. However, using an editor is not the only way to change the table model. If the setvalueAt method is called from elsewhere, any changes to the model that it makes will not automatically be reflected in the table's on-screen appearance. To make sure that the table updates itself, the fireTableRowsUpdated method of AbstractTableModel is called. This sends a TableModelEvent to any listeners registered to receive events from the model, one of which is the JTable. On receipt of this event, the table repaints itself as necessary.

That's all there is to the implementation of the editable table model. There is, however, one small point that was glossed over in this description. Suppose the user types an illegal value into one of the editable cells. For example, suppose the user tries to store the value ABCDEF as an exchange rate. Obviously, this can't be allowed. The default cell editor won't perform any validity checking on the value that the user types— it will just pass it directly to the setValueAt method. The validity checking is, in fact, performed by the constructor of the Double class when the string is given to it for conversion. If the String does not represent a valid Double, this constructor throws a NumberFormatException. As you can see, this exception is caught and the setValueAt method will return without storing a new value. The table editor framework doesn't provide any way to propagate back to the editor that an attempt was made to store an illegal value, so there is no other reasonable course to take. You might wish to display an error message to the user (using the JOptionPane class, for example), but for simplicity we have chosen to ignore illegal values, with the result that the user will simply see the cell revert to its old content on completion of the edit. The same action is taken if the new exchange rate converts to a value Double, but is negative or zero.

Having implemented an editable version of the CurrencyTableModel, it is very simple to change the example programs that we have been using so that they provide an editable table. You can experiment with such a table using the command

java AdvancedSwing.Chapter7.EditableHighlightCurrencyTable

This table is the same as the one that was shown in Figure 7-6 and, at first, will appear indistinguishable from it. The only line of code that was changed to make this table editable is this one:

JTable tbl = new JTable (new EditableCurrencyTableModel());

which replaces the original

JTable tbl = new JTable (new CurrencyTableModel ());

The code that modifies the data model is, of course, in the modified data model, while the editors and the editing capability were always available in the table but were deactivated by the isCellEditable method of CurrencyTableModel.

To change the value of a cell, double-click with the mouse in one of the editable columns (the middle two columns). A text editor will appear in the cell and you'll find that you can change the cell's content. Figure 7-1 shows how the table appears when the third column of the top row is being edited. To make the change permanent, click in another cell or press the RETURN key. Notice when you do so that the cell that has been edited is updated and the currency change is also recalculated. Furthermore, you should also see that, if the currency difference becomes negative, the corresponding cell in the third column is highlighted by the renderer installed in that column, demonstrating that the table view is being properly updated (you will, in fact, need to move the row selection away from the row containing the modified cell to see that the difference value has changed color).

Figure 7-1. Editing a table cell.

You've seen that the first phase can be initiated by the appropriate number of mouse clicks (two for a text editor, one for a combo box or a check box) in an editable cell, but there are two additional ways to begin editing. The most obvious way, which you can try by running the EditableHighlightCurrencyTable example that was shown earlier, is to move the focus to the cell to be edited using the cursor keys or with a single click and then just start typing a new value into the cell. The table UI class registers listeners that detect mouse presses and key presses and react to either by checking whether an edit should be initiated as a result. The other way to start an edit is for an application program to call one of the JTable editCellAt methods:

public boolean editCellAt (int row, int column);
public boolean editCellAt (int row, int column, EventObject evt);

The EventObject argument is used to allow the editCellAt method to decide whether an edit should be started based on some aspect of the event that caused it to be invoked. Application programs that want to programmatically start an edit will usually want to do so unconditionally and will therefore call the first variant of this method.

public void isCellEditable (EventObject evt);

Once the editor has been installed, the user interacts directly with it to edit the cell's data content. When the data has been modified, the new content will be written to the table model and the editing process terminates; the latter part of the editing mechanism will be discussed later.

The only interesting part of the editing phase is how the events that the editing component needs actually get to it. The events that are of most interest to editing components are keyboard and mouse events. Let's look first at keyboard events. As you know, keyboard events always go to whichever (single) component has the input focus. Usually, a table consists of only one component— the JTable. Therefore, at any give time, the input focus will be on the JTable or elsewhere in the application. If you are driving the JTable using the keyboard, you would give the table the focus by clicking somewhere inside its boundary with the mouse (which the table reacts to by grabbing the focus using the JComponent requestFocus method), so all keyboard events go to the JTable.

When the table is being edited, however, there are two components to be considered— the JTable and the editing component. If the editor is a text component, it needs to receive the user's keystrokes, so it would appear that the table should pass the focus to the editing component when it is installed. In fact, though, the JTable does not pass the focus to the editing component. As a result of this, keystrokes intended for the editing component will actually go to the JTable, not to the editing component, so you would not expect the user to be able to type anything into the text component, which is clearly not what happens.

However, this is not the end of the story. The table UI class registers itself as a KeyListener of the JTable and so receives notification of all keys pressed while the table has the focus. When editing is in progress, this listener takes all KEY_PRESSED events and performs special handling that works only if the editing component is a JTextField (or a class derived from JTextField). The result of this processing is that the key event will be redirected to the editor kit behind the text field, thus achieving the same effect as if the key press had been passed directly to the editor.

Keystrokes, therefore, get to the editing component only if it is a JTextField. Other editors, including the standard JComboBox and JCheckBox editors, do not receive keystrokes at all— for these editors, only the initial keystroke that activates editing is processed and even then it is not passed to the editing component. This means that it is not always possible to drive an editing component to its full potential using the keyboard.

Mouse events are, however, potentially a different matter. Mouse events are not controlled by where the input focus is directed— instead, they usually go directly to whichever component the mouse is over, the exception being when the mouse is being dragged, in which case the MOUSE_DRAGGED and MOUSE_RELEASED events go to the component that received the MOUSE_PRESSED event at the start of the drag operation. Therefore, once the editor is installed, clicking it with the mouse will cause the event generated to go directly to the editing component, not to the JTable. There is, however, a subtlety involved here.

The mouse click that starts the edit generates a MOUSE_PRESSED event that is passed to the JTable. This event, and subsequent mouse events, need to be delivered to whichever editing component is finally installed in the table. To make this possible, the table UI class remembers the component that is under the mouse when editing starts and redirects all mouse events it receives to that component, until editing is completed. This is necessary because all events after the MOUSE_PRESSED and up to the matching MOUSE_RELEASED (including MOUSE_CLICKED and MOUSE_DRAGGED, if any) will go to the JTable, not the newly installed editing component. As a result of this special handling, if you highlight the content of the editor by dragging the mouse over it, the events that this generates are passed to the editing component. This means that editor components behave normally with respect to mouse events and you can do anything with these components when they are installed inside a table that you can do when they are used on their own.

Once editing has started, there are only two ways to terminate it:

Let's first look at what happens when the conditions for ending the edit have been satisfied; later, we'll describe how these two conditions are detected.

No matter why the edit is being completed, the cleanup operation is begun by invoking the stopCellEditing method of the current cell editor; this method is part of the CellEditor interface, so it is implemented by every editor. This method is defined as follows:

public boolean stopCellEditing ();

The fact that this method returns a boolean means that it can, in theory, refuse to stop editing at any given time by returning false. If this happens, the table ignores whatever caused it to attempt to terminate the edit. The standard editors (all created using DefaultCellEditor) always return true from this method, which means that the editing operation will be terminated. The stopCellEditing method can do whatever it needs to do to clean up the editing component, but it must not lose the new value that the user selected for the cell. If this method is going to return true, it must also notify all CellEditorListeners that editing is complete. For editors derived from DefaultCellEditor, this obligation can be discharged by calling its fireEditingStopped method. Here is the definition of the CellEditorListener interface:

public interface CellEditorListener
                           extends java.util.EventListener {
   public void editingStopped (ChangeEvent e);
   public void editingCanceled (ChangeEvent e);
}

Any class can register as a CellEditorListener by implementing this interface and calling the addCellEditorListener method of CellEditor. Because all editors implement the CellEditor interface, they all support registration of CellEditorListeners. Editors derived from DefaultCellEditor inherit its addCellEditorListener and removeCellEditorListener methods and do not need to provide their own implementation.

Notice there appear to be two ways to report to a listener that editing has terminated; either the edit has stopped, or been canceled. The distinction between these two is what should happen to the table data model. When the editingStopped method is called, the edit has been ended cleanly and it is expected that the new value will be stored in the table data model. By contrast, if editingCanceled is called, any changes that the user made should be discarded. In fact, the default table editors never call the editingCanceled method, so there is no way to abandon a table edit. This interface is also used by JTree, which does call the editingCanceled method under some circumstances.

JTable implements the CellEditorListener interface and, as you saw in "Starting the Edit", registers itself to receive these events with the editor when it starts the edit. Therefore, its editingstopped method will be invoked. You'll note from the definition of the editingstopped method that its only argument is a ChangeEvent, which carries no information at all other than a reference to its source. The meaning of the source for these events is not formally defined in the Swing API. Although the editors derived from DefaultCellEditor all supply the editor as the source, JTable cannot rely on this when a custom editor is installed, so it uses its own getCellEditor method to retrieve the current editor. It then invokes the CellEditor getEditorValue method on the editor to get the new value of the table cell. The editor itself, of course, does not know what the new cell value is; to get this value, it extracts it from the actual editing component. In the case of a JTextField, for example, this involves calling the getText method. DefaultCellEditor has the appropriate code to get the new value for the three component types that it supports.

With the new value available, JTable uses the TableModel setValueAt method to update the table model. At this point, no validation of the data has been performed (unless a custom editor has performed some kind of validity checking— the default editors do not do this). It is up to the TableModel to reject values that are not legal, according to its own criteria. As you saw earlier in the discussion of the code in Listing 7-1, there is no way for the TableModel to provide feedback when it receives an illegal value— it just discards the data and leaves the cell unchanged.

The last step is to disconnect the editor from the table. This job is performed by the JTable removeEditor method, which does the following:

The repaint is limited to the area of the table occupied by the edited cell. Because all table painting is handled by renderers, this operation will actually be performed by the cell's usual renderer. While the table is editing, the editor component is responsible for drawing the content of the cell. It is possible that the renderer and the editor will display the same data in different ways, so there will be an obvious difference between the cell's appearance when it is editing. This is certainly the case for data that is edited by the standard text editors, which show a lined border when an edit is active. The default renderers for the same data types do not have a border.

Finally, having seen what happens when editing is complete, let's return to the two ways in which the table detects that the current edit should be stopped. The most obvious way is for the user to directly signal the fact as part of the editing process. If the cell editor is a JTextField, for example, the user can press RETURN to complete the edit. This will generate an ActionEvent, which must be caught and the cell editors stopCellEditing method called in response. The DefaultCellEditor implementation includes the code to register an ActionListener on the JTextField and calls stopCellEditing in its actionPerformed method. The same arrangement works if the editor is a JCheckBox: or a JComboBox: because these components also generate an ActionEvent when their state is changed.

The other way in which the user can signal the end of an edit is to click somewhere else in the table. This generates a mouse event that is caught by the table UI class. This event is actually treated in the same way as mouse events that start an edit— in fact, the same code is used. This means that the tables editCellAt method will be called, this time to determine whether to start an edit in a different cell. The description of this method that you saw earlier omitted one important fact: before deciding whether a new edit should be started, it checks whether a cell is currently being edited (using the JTable isEditing method). If so, it is immediately stopped by calling the editor's stopCellEditing method directly. When this method returns, the current edit will have been stopped and the editor removed. Any value typed into the cell will have been saved in the table's data model (assuming it was valid).

There are actually several other ways to cause the current edit to be stopped, all of which do not save the current value in the table (but nevertheless do not invoke the editingCanceled method of CellEditorListeners). These are:

Of these, only the last can be performed directly by the user. This is the only way for the user to abandon a table edit without changing the data in the table model and without having to retype the previous content.

The simplest way to add a column for the Update button is just to add a column to the table's TableColumnModel. However, every column in the TableColumnModel must correspond to a column in the TableModel, so that the data for the column can be obtained. At first, this seems like an unnatural and clumsy arrangement— after all, the button is not really part of the table data. In fact, though, as you'll see when we look at how to implement the button in "Activating the Button", having a TableModel column for it simplifies the implementation and also allows the action taken when it is pressed to be dependent on the model, which is exactly as it should be. Aside from this as yet unexplained advantage, the most direct benefit of having a column for the button is that the button's label can be held in the data model.

Fortunately, adding a column to the TableModel is a very simple matter. The existing functionality can be preserved by deriving the new model from EditableCurrencyTableModel, as shown in Listing 7-3.

package AdvancedSwing.Chapter7;

import javax.swing.*;

//An updatable version of the currency table model
public abstract class UpdatableCurrencyTableModel
                 extends EditableCurrencyTableModel {
   public int getColumnCount() {
      return super.getColumnCount() + 1;
   }

   public Object getValueAt(int row, int column) {
      if (column == BUTTON_COLUMN) {
         return "Update";
      }
      return super.getValueAt(row, column);
   }

   public Class getColumnClass(int column) {
      if (column == BUTTON_COLUMN) {
         return String.class;
      }
      return super.getColumnClass(column);
   }
   public String getColumnName(int column) {
      if (column == BUTTON_COLUMN) {
         return "";
      }
      return super.getColumnName(column);
   }

   public boolean isCellEditable(int row, int column) {
      return column == BUTTON_COLUMN ||
                    super.isCellEditable(row, column);
   }

   public void setValueAt(Object value, int row, int column) {
      if (column == BUTTON_COLUMN) {
         // Button press - do whatever is needed to update
         // the table source
         updateTable(value, row, column);
         return;
      }

      // Other columns - use superclass
      super.setValueAt (value, row, column);
   }

   // Used to implement the table update
   protected abstract void updateTable (
                           Object value, int row, int column);

   protected static final int BUTTON_COLUMN = 4;
}

Most of this code should be self-explanatory. This table model creates the extra column while preserving the existing data by delegating anything that concerns the first four columns of the table to EditableCurrencyTableModel and handling the last column itself. The getColumnCount method returns the correct number of columns by invoking the same method in its superclass and then adding 1 to account for the button column. The getvalueAt method is enhanced to return the string Update for any row in the button column. The value returned from this method will actually be used to set the buttons label; as noted above you can, if you wish, make the label dependent on the row number. For example, you might do this:

public Object getValueAt (int row, int column) {
   if (column == BUTTON_COLUMN) {
      return "Update row " + row;
   }
   return super.getValueAt(row, column);
}

As you can see, data for the other columns in the table is obtained directly from the EditableCurrencyTableModel.

There is a similar pattern in the getColumnClass, getColumnName, and isCellEditable methods, which directly handle requests for the last column and delegate others to the superclass. The getColumnClass method returns String. class for the button's column, because the data used to supply the buttons label is a string. In this example, a column-based renderer will be used to draw the button, so the exact class returned by this method is not critically important. The getColumnName method returns an empty string for the last column, so the column heading will be empty as you can see in Figure 7-3. Finally, the isCellEditable method returns true for the column occupied by the buttons data and whatever the superclass returns for the other columns. It might seem strange to return true for the button's column, but there is a good reason for this, as you'll see shortly.

The most important methods in this class are the last two. The setvalueAt method is called when the table content is being updated. Updates for most columns go directly to the EditableCurrencyTableModel setValueAt method. What does it mean to update the button column's data and why does isCellEditable return true for this column? The reason for making this column editable is tied to the implementation of the button, which you'll see in "Activating the Button". For now, notice that calling the setValueAt method to change the button column's content does not affect the button label— this much is obvious anyway, because getValueAt returns a constant value for that column. Instead, attempting to update this column results in a call to the abstract updateTable method. This method can be implemented in a concrete subclass of updatableCurrencyTableModel to provide the code needed to save the affected row's contents back to its original source.

The second thing you need for this table is a cell renderer that can draw a button. This is the simplest part, because everything you need to know to create this renderer was covered in the previous chapter. Because the renderer will draw a button, the simplest implementation is just to implement it as a subclass of JButton and return this from getTableCellRendererComponent. The code is shown in Listing 7-4.

package AdvancedSwing.Chapter7;

import javax.swing.*;
import javax.swing.border.*;
import javax.swing.table.*;
import java.awt.*;
import AdvancedSwing.Chapter6.DataWithIcon;

//A holder for data and an associated icon
public class ButtonRenderer extends JButton
               implements TableCellRenderer {
   public ButtonRenderer() {
      this.border = getBorder();
      this.setOpaque(true);
   }

   public void setForeground(Color foreground) {
      this.foreground = foreground;
      super.setForeground(foreground);
   }

   public void setBackground(Color background) {
      this.background = background;
      super.setBackground(background);
   }

   public void setFont(Font font) {
      this.font = font;
      super.setFont(font);
   }

   public Component getTableCellRendererComponent(
                   JTable table, Object value,
                   boolean isSelected,
                   boolean hasFocus,
                   int row, int column) {
      Color cellForeground = foreground !=
                 null ? foreground : table.getForeground();
      Color cellBackground = background !=
                 null ? background : table.getBackground();
      setFont(font != null ? font : table.getFont());
      if (hasFocus) {
          setBorder(UIManager.getBorder(
                         "Table.focusCellHighlightBorder"));
          if(table.isCellEditable (row, column)) {
          cellForeground = UIManager.getColor(
                          "Table.focusCellForeground");
          cellBackground = UIManager.getColor(
                          "Table.focusCellBackground");
          }
      } else {
         setBorder(border);
      }

      super.setForeground (cellForeground);
      super.setBackground(cellBackground);

      // Customize the component's appearance
      setValue(value);

      return this;
   }

   protected void setValue(Object value) {
      if (value == null) {
         setText("");
         setIcon (null);
      } else if (value instanceof Icon) {
         setText ("");
         setIcon ((Icon)value);
      } else if (value instanceof DataWithIcon) {
         DataWithIcon d = (DataWithIcon)value;
         setText(d.toString());
         setIcon(d.getIcon());
      } else {
         setText(value.toString());
         setIcon(null);
      }
   }

   protected Color foreground;
   protected Color background;
   protected Font font;
   protected Border border;
}

Because you should by now be thoroughly familiar with writing renderers, not much needs to be said about this code. The only points worth noting are the border and label handling. Every button is created with a border that depends on the current look-and-feel. The table, however, uses its own border (also look-and-feel specific) to indicate the cell that currently has the focus. To preserve this mechanism for the button renderer, a reference to the buttons original border is saved by the constructor. In the getTableCellRendererComponent method, this original border is installed unless the button cell has the focus, when the same border as that used by the other table cells is used instead. The label is controlled by the setvalue method, which is called from getTableCellRendererComponent.

The value argument passed to getTableCellRendererComponent method (and hence to setvalue) comes from the button's column in the table model. Using the UpdatableCurrencyTableModel, this value will always be a string. As you can see, string values are simply used to set the buttons label. The setValueAt implementation is, however, more powerful. If you wish, you can subclass UpdatableCurrencyTableModel and have its getValueAt method return an Imagelcon or a DataWithIcon object to get a button with an icon or a button with an icon and accompanying text. Using Java's compact inner class notation, you can even embed this kind of extension directly into the code that creates the table. For example:

JTable tbl = new JTable (new UpdatableCurrencyTableModel() {
   public void updateTable (Object value, int row, int column) {
      // Code not shown
   };

   public Object getValueAt(int row, int column) {
      if (column == BUTTON_COLUMN) {
         return new DataWithIcon("Save",
                    new ImageIcon(getClass().
                    getResource("images/save.gif")));
      }
      return super.getValueAt (row, column);
   }
});

This modified table would display buttons with the label Save and whatever the icon in the file images/save.gif represents.

Now we come to the tricky part. If you created a new version of the EditableHighlightCurrencyTable example with the changes made so far, you would see a table with five columns, the rightmost of which contained a button with the label Update in every row. However, if you click any of these buttons with the mouse or tab over to one of them using the keyboard and press space or return, you wouldn't get a very useful response.

The question is, how to get the button to click? When you click the button's drawn image with the mouse, the table will consider starting an editor. If you implement an editor that looks like a button, with the same label as the one shown by the renderer and that activates itself on the first mouse click, you could give the illusion that the table contains a real button and, for the short period of time during which the button is active, there really would be a button in the table cell. To make this work, you need to implement an editor that returns a JButton as its editing component.

It would be nice to be able to implement this editor by extending DefaultCellEditor. This would make it possible to reuse existing code that registers CellEditorListeners and fires events when editing is stopped or abandoned. However, DefaultCellEditor has three constructors that require as arguments a JTextField, a JComboBox, or a JCheckBox. There is no default constructor and no way to supply a JButton, not even as a Component. This leaves three choices:

The first of these would be the cheapest and fastest in implementation terms. Its drawbacks are that it requires more resource (in the shape of an addition component that is never used) and that it is not a neat and tidy solution. The difference between the second and third options is largely one of code reuse. The second option is undoubtedly faster to implement, but it would be very difficult to reuse, for the same reasons as DefaultCellEditor is hard to use in this case. The approach adopted here is to take the third alternative and implement a new base class called BasicCellEditor that is more flexible than DefaultCellEditor.

package AdvancedSwing.Chapter7;

import javax.swing.*;
import javax.swing.table.*;
import javax,swing.event.*;
import java.awt.*;
import java.beans.*;
import java.util.*;

public class BasicCellEditor implements CellEditor,
            PropertyChangeListener {
   public BasicCellEditor() {
      this.editor = null;
   }

   public BasicCellEditor(Component editor) {
      this.editor = editor;
      editor.addPropertyChangeListener(this);
   }

   public Object getCellEditorValue() {
      return null;
   }

   public boolean isCellEditable(EventObject evt) {
      editingEvent = evt;
      return true;
   }

   public boolean shouldSelectCell(EventObject evt) {
      return true;
   }

   public boolean stopCellEditing() {
      fireEditingStopped();
      return true;
   }

   public void cancelCellEditing() {
      fireEditingCanceled();
   }

   public void addCellEditorListener(CellEditorListener 1) {
      listeners.add(CellEditorListener.class, 1);
   }
   public void removeCellEditorListener(CellEditorListener 1) {
      listeners.remove(CellEditorListener.class, 1);
   }

   // Returns the editing component
   public Component getComponent() {
      return editor;
   }

   // Sets the editing component
   public void setComponent(Component comp) {
      editor = comp;
   }

   // Returns the event that triggered the edit
   public EventObject getEditingEvent() {
      return editingEvent;
   }

   // Method invoked when the editor is installed in the table.
   // Overridden in derived classes to take any convenient
   // action.
   public void editingStarted(EventObject event) {
   }

   protected void fireEditingStopped() {
      Object[] 1 = listeners .getListenerList ();
      for (int i = 1.length -2; i >= 0; i -= 2) {
         if (l[i] == CellEditorListener.class) {
            if (changeEvent == null) {
               changeEvent = new ChangeEvent(this);
            }
            ((CellEditorListener)l [i+1]).
                    editingStopped(changeEvent);
         }
      }
   }

   protected void fireEditingCanceled() {
       Object[] 1 = listeners.getListenerList();
       for (int i = 1.length - 2; i >= 0; i -= 2) {
          if (l[i] == CellEditorListener.class) {
             if (changeEvent == null) {
                changeEvent = new ChangeEvent(this);
            }
            ((CellEditorListener)1[i+1]).
                    editingCanceled(changeEvent);
         }
      }
   }

   // Implementation of the PropertyChangeListener interface
   public void propertyChange(PropertyChangeEvent evt) {
      if (evt.getPropertyName().equals("ancestor") &&
            evt.getNewValue() != null) {
         // Added to table - notify the editor
         editingStarted(editingEvent);
      }
   }

   protected static JCheckBox checkBox = new JCheckBox();
   protected static ChangeEvent changeEvent;
   protected Component editor;
   protected EventListenerList listeners =
                                      new EventListenerList();
   protected EventObject editingEvent;
}

public void editingStarted (EventObject evt);

public EventObject getEditingEvent ()

package AdvancedSwing.Chapter7;

import javax.swing.*;
import javax.swing.table.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;
import AdvancedSwing.Chapter6.DataWithIcon;
public class ButtonEditor extends BasicCellEditor
                  implements ActionListener,
                  TableCellEditor {
   public ButtonEditor(JButton button) {
      super(button);
      button.addActionListener(this);
   }

   public void setForeground(Color foreground) {
      this.foreground = foreground;
      editor.setForeground(foreground);
   }

   public void setBackground(Color background) {
      this.background = background;
      editor.setBackground(background);
   }

   public void setFont(Font font) {
      this.font = font;
      editor.setFont(font);
   }

   public Object getCellEditorValue() {
      return value;
   }

   public void editingStarted(EventObject event) {
      // Edit starting - click the button if necessary
      if (!(event instanceof MouseEvent)) {
         // Keyboard event - click the button
         SwingUtilities.invokeLater(new Runnable() {
            public void run() {
               ((JButton)editor).doClick();
            }
         });
      }
   }

   public Component getTableCellEditorComponent(
            JTable tbl,
            Object value, boolean isSelected,
            int row, int column) {
      editor.setForeground(foreground != null ? foreground :
                                      tbl.getForeground());
      editor.setBackground(background != null ? background :
                                      tbl.getBackground());
      editor.setFont(font != null ? font : tbl.getFont());

      this.value = value;
      setValue(value);
      return editor;
   }

   protected void setValue(Object value) {
      JButton button = (JButton)editor;
      if (value == null) {
         button.setText("");
         button.setIcon(null);
      } else if (value instanceof Icon) {
         button.setText("");
         button.setIcon((Icon)value);
      } else if (value instanceof DataWithIcon) {
         DataWithIcon d = (DataWithIcon)value;
         button.setText(d.toString());
         button.setIcon(d.getIcon());
      } else {
         button.setText(value.toString() ) ;
         button.setIcon(null);
      }
   }

   public void actionPerformed(ActionEvent evt) {
      // Button pressed - stop the edit
      stopCellEditing();
   }

   protected Object value;
   protected Color foreground;
   protected Color background;
   protected Font font;
}

package AdvancedSwing.Chapter7;

import javax.swing.*;
import javax.swing.table.*;
import javax.swing.event.*;
import java.awt.*;
import java.awt.event.*;
import AdvancedSwing.Chapter6.*;

public class UpdatableHighlightCurrencyTable {
   public static void main(String[] args) {
      JFrame f = new JFrame("Updatable Highlighted Currency
                                                      Table");

      JTable tbl = new JTable (
                      new TestUpdatableCurrencyTableModel());
      tbl.setDefaultRenderer(java.lang.Number.class,
            new FractionCellRenderer(10, 3,
            SwingConstants.RIGHT));

      TableColumnModel tcm=tbl.getColumnModel();
      tcm.getColumn(0).setPreferredWidth(150);
      tcm.getColumn(0).setMinWidth(150);
      TextWithIconCellRenderer renderer =
                               new TextWithIconCellRenderer();
      tcm.getColumn(0).setCellRenderer(renderer) ;
      tbl.setShowHorizontalLines(false);
      tbl.setIntercellSpacing(new Dimension(1, 0));

      // Add the stripe renderer in the leftmost four columns.
      StripedTableCellRenderer.installInColumn(tbl, 0,
                  Color.lightGray, Color.white,
                  null, null);
      StripedTableCellRenderer.installInColumn(tbl, 1,
                  Color.lightGray, Color.white,
                  null, null);
      StripedTableCellRenderer.installInColumn(tbl, 2,
                  Color.lightGray, Color.white,
                  null, null);
      StripedTableCellRenderer.installInColumn(tbl, 3,
                  Color.lightGray, Color.white,
                  null, null);
      // Add the highlight renderer to the difference column.
      // The following comparator makes it highlight
      // cells with negative numeric values.
      Comparator cmp = new Comparator() {
         public boolean shouldHighlight(JTable tbl, Object
                                 value, int row, int column) {
            if (value instanceof Number) {
               double columnValue =
                            ((Number)value).doubleValue();
               return columnValue < (double)0.0;
            }
            return false;
         }
      };
      tcm.getColumn(3).setCellRenderer(
                            new HighlightRenderer(cmp,
                            null, Color.pink,
                            Color.black, Color.pink.darker(),
                            Color.white));

      // Install a button renderer in the last column
      ButtonRenderer buttonRenderer = new ButtonRenderer();
      buttonRenderer.setForeground(Color.blue);
      buttonRenderer.setBackground(Color.lightGray);
      tcm.getColumn(4).setCellRenderer(buttonRenderer);

      // Install a button editor in the last column
      TableCellEditor editor = new ButtonEditor(new JButton());
      tcm.getColumn(4).setCellEditor(editor);

      // Make the rows wide enough to take the buttons
      tbl.setRowHeight(20);

      tbl.setAutoResizeMode(JTable.AUTO_RESIZE_OFF);
      tbl.setPreferredScrollableViewportSize(
             tbl.getPreferredSize());

      JScrollPane sp = new JScrollPane(tbl);
      f.getContentPane().add(sp, "Center");
      f.pack();
      f.addWindowListener(new WindowAdapter() {
         public void windowClosing(WindowEvent evt) {
            System.exit(0);
         }
      });
      f.setVisible(true);
   }
}

package AdvancedSwing.Chapter7;

import AdvancedSwing.Chapter7.UpdatableCurrencyTableModel;

public class TestUpdatableCurrencyTableModel
               extends UpdatableCurrencyTableModel {
   public void updateTable(Object value, int row, int column) {
      System.out.println("Update for row " + row + "
                                                   required.");
      System.out.println("Values are " +
              getValueAt(row, 1} +
              ", " + getValueAt(row, 2) +
              "; diff is " + getValueAt(row, 3));
   }
}

The setEditingColumns method is supplied with an array of integers that specifies the column numbers of the columns that participate in tab traversal editing. Relating this to the currency table in which the two exchange rate columns should support tab traversal, you might invoke this method as follows:

int[] tabColumns = { 1, 2 };
tbl.setEditingColumns (tabColumns);

However, this code hides a subtlety that we've mentioned already in this chapter in different contexts. Are the column numbers specified in terms of the column order in the data model or as indices in the tables TableColumnModel? Initially, columns 1 and 2 in the data model might actually be displayed in columns 1 and 2 of the table, but this needn't always be the case and, even if it is, the user could reorder the table columns at any time. From the programmers point of view, the most sensible option is to specify the column indices in terms of the columns in the data model, because these indices are invariant— the exchange rates are always in columns 1 and 2 of the data model. This is, in fact, how the setEditingColumns model method in Listing 7-9 is implemented. As you can see, it stores the column list in an instance variable called editingColumns, which can be retrieved at any time using the getEditingColumns method.

The problem with saving data column model indices is that the table methods that deal with editing and use a column number (such as editCellAt) all work in terms of the TableColumnModel indices. As you'll see, this means that when the tab key is being used to move the edit focus around the table you'll have the TableColumnModel index to work from, not the data model index. For this reason, it is necessary to map from data model indices to TableColumnModel indices, which can be done using the JTable convertColumnIndexToView method.

The most natural way for the tabbing operation to work is for the tab key to move the editing focus across each row from left to right and to wrap back to the leftmost participating column at the end of the row. If tab is used with shift, this order would be reversed. When the decision is being made as to which cell to edit next, it would be useful to have an array of column indices in TableColumnModel order. Then, to move the edit focus to the right, you would just move to the next element in the array from the one currently in use and to move to the left you move back by one entry. Thus, when setEditingColumns is called, the array of column numbers is converted to an array of TableColumnModel indices and stored in the instance variable viewEditingColumns for use when the TAB key is being processed. The conversion is performed by using the convertEditableColumnsToView method.

The convertEditableColumnsToView method is fairly simple. It first creates a new array of the same size as the one passed to setEditingColumns and walks down the array of data model indices converting each to the corresponding TableColumnModel index and storing it in the next slot in the new array. Because not all the data model columns need be included in the table column model for a particular table, it is possible that one or more of the columns designated as participating in tabbing might not have a corresponding TableColumnModel index. In this case, convertColumnIndexToView returns -1 and that column is ignored. As a result, the final array may be shorter than the one initially passed to setEditingColumns and, if it is, it is truncated by copying it to a new array of the appropriate size. Finally, the new array is sorted into ascending order, so that the leftmost participating column comes first, followed by the next one to its right and so on. This makes it possible to see the tabbing order in terms of the indices of the table columns as they are displayed by reading the array from the start to the end.

When setEditingColumns returns, then, the viewEditingColumns variable contains the tabbing columns in sorted order. However, this is not quite the end of the story. Suppose the user reorders the table columns. If this happens, the mapping created by setEditingColumns might become incorrect.

For example, in the initial configuration of the currency table, the data model column indices map directly to the TableColumnModel indices, so the viewEditingColumns array would initially contain the values {1, 2}. Now, if the leftmost exchange rate column were dragged to the left of the table, its TableColumnModel index would become 0 instead of 1 and it would be necessary to change viewEditingColumns to {0, 2} instead. Furthermore, if the rightmost exchange rate column were now dragged to the left to occupy position 0, the correct value of viewEditingColumns would now be {0, 1} and the tab order between the two exchange rate columns would be reversed in terms of their column headings, but would still be left to right across the table. To recompute the array values it is necessary to gain control whenever the order of columns in the TableColumnModel changes.

To be notified of changes to the TableColumnModel, it is necessary to implement a TableColumnModelListener. Fortunately, JTable already implements this interface and registers itself as a TableColumnModelListenerof its own TableColumnModel. To receive notification of column order changes, TabEditTable simply overrides the following TableColumnModelListener methods of JTable:

Each of these methods simply calls the JTable implementation and then invokes convertEditableColumnsToView to convert the data column model indices (stored in editingColumns) to the TableColumnModel indices that are correct for the new column order.

It remains to actually implement the code that will capture the tab key and move the edit focus elsewhere. As noted above, it is necessary to gain control when editing is started and add a listener to receive the tab key. Because editing is always begun by calling the JTable editCellAt method, the natural thing to do is to override this method in TabEditTable. If you look at the implementation of editCellAt in Listing 7-9, you'll see that it first checks whether the edit is actually going to start. If so, it then verifies that the cell about to be edited is in the list of columns for which tabbing should be active. Note that, because editCellAt receives a column number expressed in terms of the TableColumnModel ordering, this check is made by looking at the viewEditingColumns array, not the original array of data model indices supplied to setEditingColumns. If the cell is in this list, the following steps are taken:

The last step attempts to ensure that keys are passed directly to the editing component, but it is not sufficient because the table sometimes grabs the focus back. Hence, it is still necessary to install a KeyListener on the table as well.

As each key is passed to the editor component, the KeyListener implemented by the inner class TabKeyListener is notified. The keyPressed method of this class checks whether the key is a tab key and if it is, the current edit is stopped by invoking the editor's stopCellEditing method. If this works, the editor has been removed and the edit focus is moved to the next eligible cell by calling the TabEditTable moveToNextEditor method.

The moveToNextEditor method is given the row and column number of the cell last edited and a flag indicating whether it should move forward or backward in the tabbing order; this flag is set to indicate backward movement if the shift key was pressed together with tab. This method can be overridden to provide any kind of tabbing behavior that you want. The default implementation provides the natural left-to-right or right-to-left tabbing order described earlier in this section. It does this by using the editing column number, which is a TableColumnModel index, to locate its current place in the viewEditingColumns array. If it is moving forward, it selects the column in the next entry of the array; otherwise, it selects the previous entry. If this would involve moving off the end of the array in either direction, the row number is incremented or decremented as necessary and the next column is taken as the one in the first or last entry of the viewEditingColumns array. Either way, the last step is to call editCellAt to start an edit in the new cell. However, this is not done directly— instead, the operation is deferred using the Swingutilities invokeLater method, which allows key processing to complete before the new edit starts. Notice also that the new cell being edited is made the currently selected cell by manipulating the table's row and column selection models.

You can see how this works in practice using the following command:

java AdvancedSwing.Chapter7.TabbableCurrencyTable

First, start an edit by double-clicking somewhere in the column headed Yesterday, make a change, and then press tab. When you do this, you'll find that the new value is written to the table and the cell in the Today column to its right starts editing. As you continue to press tab, you'll find that you can access all the exchange rate values in turn, but not any of the other cells. Also, you'll find that you can use shift and tab to traverse the table in the other direction and that the operation wraps when you reach the top or bottom of the table.

To verify that this mechanism is resilient to column order changes, try dragging the currency rate columns to various locations within the table and then start an edit and press the tab key. You'll find that tabbing still works, that it still allows you to access only the exchange rate columns, and that tab continues to move you from left to right and top to bottom, even if you swap the order of the two editable columns.