JDK-4256006 : Typing into a JTable cell doesn't send focus to cell
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.2.2
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 1999-07-21
  • Updated: 1999-09-18
  • Resolved: 1999-09-18
Related Reports
Relates :  
Description

Name: skT88420			Date: 07/21/99


/*
  Program to illustrate the caret bug.

  Typing into an unfocussed cell fails to transfer the focus to 
  the cell editor.
  
  To reproduce, run this program. Click into any cell a single 
  time. A caret will not appear. At this point, the cell has a 
  colored outline, indicating that the JTable has the focus, 
  rather than the cell editor. So the caret should not be 
  visible yet.
  
  Now, start typing. The cell outline will change to black, 
  indicating that the focus has shifted to the cell editor. 
  The text will appear as I type, but the caret is still 
  missing. By now, it is clear that there is a bug.
  The caret should always be visible during typing.
  
  It appears that, even though the cell is outlined in black, 
  and I can type into the cell, it still doesn't have the focus.
  You can see this by hitting an arrow key. The focus will move 
  to a different cell, rather than changing the caret position.
  This shows that the cell editor doesn't actually have the 
  focus, as it should.
  
  Once I have started typing, I can click into the cell, and the 
  caret will finally appear. Now the arrow keys will  move the
  caret.
  
  This behavior is discussed in bug 4188907. That bug was 
  erroneously closed. Please reopen that bug, rather than 
  creating a new bug. I don't want to lose the votes this bug 
  has already accumulated.

*/

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

public class JTableFocusBug
{
  public static void main(String[] args)
  {
    JFrame mf = new JFrame("Caret in JTable Bug");
    WindowListener wl = new WindowAdapter()
    {
      public void windowClosing(WindowEvent evt) { System.exit(0); }
    };
    mf.addWindowListener(wl);
    mf.setBounds(10, 10, 400, 400);
    
    JScrollPane scroller = new JScrollPane(new JTable(new BugModel()));
    mf.getContentPane().add(scroller);
    mf.show();
  }

  private static class BugModel extends AbstractTableModel
  {
    public int getRowCount() { return 3; }
    public int getColumnCount() { return 3; }
    public Object getValueAt(int row, int col) { return "" /* + row + ", " + col*/; }

    BugModel() { super(); }
    
    public boolean isCellEditable(int row, int col)
    {
      return true;
    }
  }
}
(Review ID: 88158) 
======================================================================

Comments
EVALUATION Since the submitter has specifically asked this bug to remain open we'll leave a place for people to vote for this - but the response is essentially the same. There has to be a way to tell visually what pressing, for example, left-arrow - it will do: it will either move one cell to the left or one character. Which it does is arguably best indicated by the focus. When the table has focus it draws one of its cells specially, when the enclosed text field has focus it uses a carat. Tables define the arrow keys as cell movements - which terminate an edit incidentally. Editors can define the arrow keys to perform any kind of inter-cell naviagtion. When a left arrow is acted on by the table, editing is stopped in the current editor. This may, in turn, change data values in an application or database. So: a) this can be an important distinction and b) it is not strictly true that the textfield has focus In fact, the table has focus here and is forwarding the keys that it doesn't define to the current editor. That's really the design here, if you have ideas for a better design please send it in - we can't think of a better way to achieve the effect of having an interface which allows users to tell what is going to happen when they press a key - and this seems important. Arghh, I closed this hoping to reopen 4188907 and have just found out we cannot reopen bugs from this state. Sorry ... philip.milne@eng 1999-09-17
17-09-1999