This is in response to the evaluation of bug 4256006. In spite
(or because) of what the evaluation said, I remain convinced that
this is a bug.

(I have included the bug report below, with the test case.)

The evaluator asks: "That's really the design here, if you have
ideas for a better design please send it in "

Okay, here goes. I propose you use the existing design. If I
edit a cell using the code below, and double-click into the cell.
You now get a focussed cell, with a blinking caret, into which
you can type. If you hit an arrow key, the cursor moves. The
selected cell doesn't change.

That's the design. Tha's also the behavior I want to see, and
it's already implemented. However, if you follow the instructions
described below, you get entirely different behavior, which is
clearly a bug.

What you get is a cell that appears to have the focus (it has a
black outline) and into which you can type, but the caret doesn't
blink. Once I start to type, I want to see exactly the same
behavior that I see if I double-click into the cell. The fact
that I can get two different behaviors when I enter text is
clearly a bug.

It is also unquestionably a bug when I can type without a caret.
My users are complaining about this issue. If you have any doubts,
or if you would like to discuss this issue with me, please call
me at 626/685-5661. I have submitted this bug three times before,
and it sometimes gets accepted, then closed with an evaluation
that fails to address the issue of the missing cursor. It's very
frustrating to submit the same bug over and over again.

Here is the original report.

/*
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: 95618) 
======================================================================

N/A

In Merlin-beta we have added a new property to the JTable: 
"surrendersFocusOnKeystroke" to address this issue. The property 
is false by default so the behavior of the JTable is backward 
compatible with previous releases. By setting the property value 
to true, the JTable is put in a mode where typing in a cell 
transfers focus to the editor automatically. The key 
difference in this mode is seen in the the behavior of 
horizonatal arrow keys which will effect intercell movements 
instead of changing the selected cell in the JTable. The 
blinking caret is also visible in this mode as the editor 
component has genuinely recieved the focus after a key is 
pressed. 

  xxxxx@xxxxx   2001-03-28

I feel this is unquestionably a bug, not an RFE. The evaluator of bug 4256006
disagrees.
In an email to me, he said "If you want to drum up support for it as a bug,
 please feel free 
to do so on the Net.  This could take the form of having users put comments in
the new 
bug #, or any equivalent form you choose."
Please put your two cents in. Should this be marked as a bug, or a
"request for 
enhancement"?

This is very, very clearly a bug. I have the same problem with customers
complaining
about it all over again, and as a result have had to replace every single one
of my 
JTables and cell renderers with custom ones, just to achieve the behaviour
which I think
should be the default behaviour anyway. 

It is definitely a bug: One gets different behaviour depending on the action
which caused the cell editor to show:
If one uses the mouse to 'activate' a cell (doubleclick in case of
DefaultCellEditor), the table correctly indicates the cell's focus, calls up
the cell editor AND gives focus to the editor (hence we get the beloved caret)
HOWEVER,
if one 'activates' the cell by hitting a key,  the cell editor gets shown (for
instance: different background color in custom editors), it even gets the very
key to process, that called up the editor (very nice!), BUT (as focus listeners
prove) it DOESN'T get focus hence we don't get the caret BUT we can edit!!!
The navigational keys curretnly do work correctly:
If the editor has focus (eg. caret showing) they move the caret, else they move
the JTable's focus to another cell. Very fine so far.
The solution is simple:
The cell editor mustn't show WITHOUT having been given FOCUS by the JTable!!!!
When the cell editor gets invoked (by non-navigational) KEYSTROKE it must get
focus as if a mouse event did activate it!
Nothing else is needed, we're still consistent with what the reviewer of bug
4256006 said about "the design":
the JTable's focus can be in one of two states:
- cell renderer shown: JTable owns focus, responds to navigational keys, moves
focus to other cells
- cell editor displayed: Editor has focus, caret is shown(!), left-right moves
caret
Bottom line:
whenever a cell editor is displayed it must have got focus from the JTable, no
matter how the editor got invoked, be it mouse click OR KEYSTROKE!!
Only then we could use the JTable in keyboard only environments with the same
delight as in mouse centered situations.
Dear Reviewers,please feel free to contact me for further discussion or source
examples for that bug!
This bug and the JTable's navigational code ignoring "false" returned
from stop-editing() are true show stoppers, for field level validating in
keyboard only environments ("order entry","call center app",
...)

No more to say... This ist really a bug!

No question.  Most definitely *IS* a bug....

No question.  Most definitely *IS* a bug....

I agree that this is a bug.

When my users type in a text box, they need a caret. If its not there then its
a bug. I would vote for this but all three of my votes are on another focus
bug. (4199374)

No question. Most definitely *IS* a bug....

Of course it is a bug.  How could you argue otherwise?

I agree, but I have one more proposition:
a key should be which starts editing but don't
changes the cell contents.
For example, <Space>, <Ctrl+Enter> or <F2> (as in MS Excel).

By design, F2 starts editing. (There's a bug there, too, but Sun acknowledges
that bug.)

Ivan Bolcina
ibolcina@icos.si
This is clearly a huge bug. The JTable should act as, for example, MS Excell.
The problem is in JTableUI. The work-around is to change JTableUI and post it
with your project. That way,it works fine, but......

Bug.  You know it.  I know it.  We all know it.  Please listen.

I have been struggling with this for a month now.  There is no easily found
workaround as
far as I can tell and it is definately a bug in my opinion.  Related is the
fact that tabbing 
cell to cell causes, when shifting to type say the # char, the table to stop
allowing you
to edit cell until you double click the cell.

MLESK has posted an interesting workaround to this problem under bug 4256006. 

The current behavior is apparently designed to let the arrow keys move from
cell to cell, instead of from character to character. While this is often a
useful feature, it has three problems. First, the absence of a cursor is
confusing and unclear to the user. Second, it's not clear how the user can
toggle between the two states. (f2 toggles.) And third, when the users click
into a cell and start typing, they probably want the cell editor to gain the
focus.
JTable's behavior is similar to that of clumsy behavior of Microsoft Excel,
except that Excel always shows the cursor when the user is typing text.
A common convention used by many GUI applications (which I also wish Excel
would adopt) is to use the control key to toggle between the two arrow key
states. In other words, if the cell editor has the focus, then the arrow keys
move from one letter to the next, while control-arrow will move to a different
cell. If the table has the focus, then arrow keys move from cell to cell, and
control-arrow sends the focus to the Table Cell Editor. This is more intuitive
(and less arbitrary) than using the f2 key to toggle between the two states. It
also eliminates the inconsistent third state, where the arrow keys don't move
the caret. In any case, regardless of what the arrow keys do, the caret should
ALWAYS be visible while the user is typing.

hmmm sorry about the <BR> ...

This is clearly a *BUG* !! I hope this will be fixed soon, but I doubt since
sun seems <BR>
to not care about that. I think it is a pitty to claim oneself opensource &
free and not to care <BR>
about constructives remarks of the users to make the product better...
<BR>

it's a BUG - it creates an ambiguous definition of select all (cells or text?),
doesn't show 
caret and doesn't give clear visual feedback on where the focus is.  i'm with
olegnitz in 
that keys other than F2 could invoke the editor.

IMHO, it's a bug, and one that needs to be fixed properly ASAP.  In the
meantime, though, here's a workaround that seems to do the trick, at
least in a small test app.
import java.util.EventObject;
import javax.swing.JTable;
import javax.swing.table.TableModel;
 
public class FocussedTable extends JTable {
 
  public FocussedTable(TableModel model) {
    super(model);  // no pun intended
  } // FocussedTable
 
  public boolean editCellAt(int row, int column, EventObject e) {
    boolean retval = super.editCellAt(row, column, e);
    if (retval) editorComp.requestFocus();
    return retval;
  } // editCellAt
 
} // FocussedTable

i have tried some of the workarounds involving requestFocus() for the editor
component. 
they seem to work but they act peculiar for some characters like "#"
and "(". i.e. these keys 
seem to get consumed and therefore don't invoke the editor.  maybe its my VM/OS
configuration
of NT SP5/1.2?  has anybody else noticed this behaviour.
also, i tried another workaround by substituting the basicTableUI with my own
that had a
different keyTyped(KeyEvent e) method which 
- invoked the editor
- requested focus on the editor
- redispatched the key to the editor if it is a textcomponent.
this handles the "#' keys properly but still has the side effect of having

press TAB or Enter twice to leave the editor.
anyone else had success with overriding UI's? email me at ddick@nitidus.com

nitidus reports that a "side effect" of his workaround is that it now
takes two tabs to leave the cell. In my tests, this isn't caused by his
workaround, it's the default behavior of the JTable. When the cursor isn't
visible, it only takes a single tab to move to the next cell. But when the
cursor is visible, it takes two. The first tab puts the table into the odd
state, and the second tab moves to the next cell. 
I find this behavior counter-intuitive and very non-standard. 

i tried a couple of additional more things that helped...

- when overriding the table ui, i unregistered the TAB & Enter keys (with
& without the shift 
modifier) via table.unregisterKeyboardAction( KeyStroke ); 

- in the keyTyped() method i put some code like this at the beginning...

if (key==VK_TAB || key==VK_ENTER) {
  if (table.isEditing()) { table.editingStopped(null); }
  if (/*i want the editor to advance to the next cell - in my case, i do */)
  { ((cMyJTableExtension)table).selectNext( keyStroke.getModifiers() /* pass
modifiers - if SHIFT then go backwards */ ); }
  e.consume();
  return;
}
....continue with other keyTyped() code...


this basically makes you responsible for handling the Enter & Tab key
movement. 
it requires a selectNext() method routine somewhere (i stuck in the JTable
class) which simply
advances the selection on cell.

notes: i consumed the event, don't know if that's good or bad but it didn't
seem to hurt.
 i made a call to editingStopped(Event) with a null parameter; this looks
dangerous/bordering 
 on suicidal but it works for now because it ignores the parameter.

- when checking the key, i used 
   KeyStroke keyStroke = KeyStroke.getKeyStroke(e.getKeyChar(),
e.getModifiers());
and then checked its keycode. it didn't quite work as expected when i got the
value via 
the event...hmmm.


derek (nitidus)

Swing is said to have a pluggable Look'n Feel. Well, then check the Windows
L&F and you will see that Swing does not behave like Windows. I don't care
if you wish to have the native L&F the way you have but make the Win
L&F behave like Windows.

This is definitely a bug!!! Our company's product series involves a cheap
standard system and an expensive enterprise system. The standard was written in
Visual Basic. The enterprise in Java. Both use a lot of gui-tables. Now we
convinced the customers who had been using the standard product to switch to
the enterprise product. And each of those clients have been complaining that
"the table editing in the expensive product is absolutely
unacceptable". This means that I have to go through lots of tedious work
making my own cell editors. And so do most of the other Java developers.

Please fix this in jdk1.3

This is unquestionably a BUG!!!
In bug 4256006, u can find a piece of code to slove this 
problem,but not perfection!

if u do,please mailto redarmy_wfj@990.net.Thanks.

I also agree that this is a bug.  I was trying to solve a
slightly different
problem and thought that I could use a CellEditorListener to
detect when
the user cancels the editing by using the Escape key. 
However, I can
not get a editingCanceled event to happen.  So with the
focus problem
and the editingCanceled problem, I just can't tell when the
user aborts
the edit.

Everyone seems hooked on the cursor being there and 
blinking.  What's killing me is that the key listeners on
the on our table cell editors don't get fired.  We're
getting bugs filed that invalid data can be entered in a
table cell, the real cause of it is that the user hasn't
double clicked on the cell.  Definately a bug, I've never
used a GUI API that behaves like this.

Fix this, I need real keyboard support for speed of access to table entry.
It is a bug.

Our customers are complaining also.  I think it's obvious 
to everyone you need that caret to get feedback on 
editing.  I wish Sun would stop the typical bug report b.s. 
(oh, that's not a bug, it's the way we designed it [well, 
it's a crappy design, then]) games  and just fix the %^&* 
thing already.

I have customised JTable to that the cells can be any swing control component and I have just implemented 
a focus manager to shift focus between cells. My components are getting the focus (I can check that in 
focusGained method) but the caret is not visible. Whatever text I type is also not visible. But when I 
minimize my UI and bring it up again the text is visible, the caret is still invisible. I guess this is related to 
what is being discussed here. Any suggestions as to what can be done to override this behaviour?

a bug

In 1.3, this is a bit easier to work around.  Subclass 
JTable and override processKeyBinding as follows:

    protected boolean processKeyBinding(KeyStroke ks, 
KeyEvent e,
					int condition, 
boolean pressed) {
        boolean value = super.processKeyBinding( ks, e, 
condition, pressed );

        // Make sure that the editor component has focus.
        if ( isEditing() ) {
            getEditorComponent().requestFocus();
        }
        return value;
    }

This is unquestionably a BUG!!!

What about just having two modes, one with the functionality as is, the other where the 
click-then-keypress functionality matches that of double clicking (which IMO is more instinctive)?

This is a bug and needs to be fixed. My user are also 
complaining about this stupid behavior.

This is clearly a bug.  

Requesting consistent behavior should never be considered 
an ENHANCEMENT. 

According to Sun's reaction to bug 4256006 they see the 
current behaviour as consistent. While I do not agree with 
this I can see the value of that argument. The solution 
would be to offer a choice in behaviour:

boolean getRequestFocusOnEditorSelection ()

void setRequestFocusOnEditorSelection (boolean requestFocus)

This way those that feel that the current behaviour is 
consistent can use that, while anyone else can implement 
the behaviour his users find consistent.

This produces a crazy inconsistency between what the user sees and what the table cell value actually 
is. Two bug votes from me.

This is definitely a bug.

If sun want to give the table focus instead of the cell 
when the user single clicks on the cell, that's fine. But 
there's no reason why the user should be able to type into 
the cell, if the table has focus. You can't type into a 
cell who's editor is a combo box when the table has focus. 
I want to exclude certain characters (I overrode JTextField 
to do this) but if the user clicks once on the cell, they 
can type those characters in.

I'd like to recommend briar's solution on this bug dated 
Thu Dec 09 23:56:26 GMT+00:00 1999
it seems to create exactly the behaviour I want.

Definately a bug, along with numerous other JTable bugs.

My vote for an ugly and annoying BUG.
I also noticed that *everybody* think the same way.

That's definitely a bug - got all my votes.
That undefined focus-state of table/editorcomponent is seriously hindering _every_
slightly advanced feature of table editing (like validation f.i).

Unfortunately it's not the only bug with table editing. In the process of fixing
that (for swing11) I had to modify nearly every component/delegate/handler is 
connected to the editing process: starting with XXTableUI (here change the 
keyhandler to not routing the keys - or the actions found for them - to the
editorComponent), going over the DefaultCellEditor (which simply does not 
comply to it's contract) to XXComboBoxUI plus the JComboBox (internally they do
some _very_ dirty tricks). 

Jeanette

bug - I fixed that edit

I think it is a total bug.
Before I found this page in the swing forum I tried many things, but nothing works.
So I thank you for the very good working solution of this BUG. 

It's a bug...
I had the same problem but I made it work in some way ??

BUG and I can't fix it in 1.3 - workarounds just don't work.
I get focus for the first invocation only after that no
caret even after calling requestFocus(). Only covering and 
exposing the windows gets it to paint focus and caret in 
the JTextField. To class this as an enhancement is a very 
very lame cop out on behalf of the sun developers.

Bug or poor design. Editing of JTable cells as implemented 
simply is not intuitive for the user.  Puts us in a 
position of having to sheepishly defend our choice of Java 
while we work furiously at trying to find an acceptable 
workaround.

Typing without a caret is like writing with an invisible 
pen. Pretty damned hard to see where you're going. This is 
a bug, made worse by being inconsistent with the mouse 
selection (which is intuitive and acceptable). So, it's a 
bug, and Sun should fix it. (The fact that MS got it right 
in Excel should encourage Sun to do at least as good, if 
not better.)

This is clearly a bug.  It is causing developers to write 
work arounds ether by creating their own cell editors or 
elaborate manager schemes that transfer focus between 
different text fields / cells.  Please fix this ASAP.

/* Two issues are mixed together here. One is that there is caret
as you type. The other is that, when you type into a cell, the
focus remains with the table. (In this state, you won't see the
blinking caret.) If you click again, the focus will shift to the cell
editor, and the blinking caret will appear. The arrow keys will
behave differently under these two states. When the table has the
focus the arrows will move from cell to cell. When the cell editor
has it, the arrows will move the text caret.

Sun's fix in JDK 1.4 will only address the second issue. JTable will
have a surrenderFocusOnKeystroke property. If you set it to true,
the cell editor will always have the focus, and you'll always see
the blinking caret.

If you can't use JDK 1.4, or if you want the table to keep the
focus, try this to get the caret.

This installs a custom caret which doesn't hide itself when the cell
editor loses the focus.

One disadvantage is that there is no visual cue to
tell you whether the table or the cell editor has the focus. (Sun's
visual cue is to hide the caret.)
You can easily add your own visual cue by changing the cell editor's
border when it gains or loses the focus. */
import javax.swing.*;
import javax.swing.text.*;
import javax.swing.table.*;
import java.awt.event.*;

public class BetterTable extends JTable
{
  // You'll want to add constructors. They should all call init().
  BetterTable(TableModel mdl)

  {
    super(mdl);
    init();
  }

  private void init()
  {
    // Either one of these two lines fixes the problem,
    // but they produce different behavior by the arrow keys

//    setSurrendersFocusOnKeystroke(true); // This requires JDK 1.4
    installCaret(); // This works on JDK 1.3, 1.2. & 1.1
  }

  private void installCaret()
  {
    DefaultCellEditor edt
      =(DefaultCellEditor)getDefaultEditor(Object.class);
    JTextComponent tc=(JTextComponent)edt.getComponent();
    tc.setCaret(new TableCaret(tc.getCaret()));
  }

  private class TableCaret extends DefaultCaret
    implements ComponentListener
  {
    int myBlinkRate;
    TableCaret(Caret oldCaret)
    {
      super();
      // save the old blink rate.
      myBlinkRate = oldCaret.getBlinkRate();
    }

    /**
     * The key to always showing the caret is in overriding the
     * focusLost method. The base class hides both the caret and the
     * selection when it loses the focus. By overriding
     * and doing nothing, both remain visible.
     */
    public void focusLost(FocusEvent e) { }

    /**
     * Since the caret and selection aren't visible by default,
     * we need to turn them on when the caret is installed.
     */
    public void install(JTextComponent tc)
    {
      super.install(tc);
      // This next line has problems in JDK 1.4
//    setBlinkRate(myBlinkRate);// set the blinkRate before setVisible
      setVisible(true);         // or it won't blink the first time.
      setSelectionVisible(true);

      // Use this for JDK 1.4 or JDK 1.3 to set the blink rate.
      // It won't work in JDK 1.2 or 1.1
      tc.addComponentListener(this);
    }

    // This ComponentListener is only needed in JDK 1.4 to
    // prevent a strange but inconsequential NullPointerException.
    // It fails in JDK 1.2 and 1.1.
    //
    // In JDK 1.3 or earlier, you can remove the ComponentListener
    // code and set the blink rate in the install() method. Be sure to
    // put it before the call to setVisible(). (Except for the
    // spurious exception, that actually works fine in JDK 1.4, too.)
    public void componentResized(ComponentEvent e)
    {
      setBlinkRate(myBlinkRate);
      setVisible(true);
      getComponent().removeComponentListener(this);
    }
    public void componentMoved(ComponentEvent e){}
    public void componentHidden(ComponentEvent e){}
    public void componentShown(ComponentEvent e){}
  }
}

I discovered following workaround. When create custom 
editor, use slightly modified JTextField:

new JTextField() {
    public void addNotify() {
        super.addNotify();
        requestFocus();
    }
});

I would like to thank the Sun Developers for realising the importance of this issue and for getting it fixed.

What needs to be kept in mind is the fact that if Java programs are to be true Windows alternatives, UI 
behaviour should very much be the same as - say, in this case, Excel.

Anyway, thanks!

I would like to thank the Sun Developers for realising the importance of this issue and for getting it fixed.
What needs to be thought of is the fact that if Java programs are to be true Windows alternatives, UI 
behaviour should very much be the same as - say, in this case, Excel.

Anyway, thanks!

Yours sincerely,
Sven Burgener

but when i explicitly want to handle the caret position in the table cell which contains  textfield as renderer  and  editor , then it is moving 2 caret positons at a time how to hanlde this can you please suggest on this .
please find the sample code as below.

 if (ke.getKeyCode() == KeyEvent.VK_LEFT) {

            if (((JTextField) ke.getSource()).getCaretPosition() != 0) {
                ((JTextField) ke.getSource()).setCaretPosition(((JTextField) ke.getSource()).getCaretPosition() -1);
            }

        }

but when i explicitly want to handle the caret position in the table cell which contains  textfield as renderer  and  editor , then it is moving 2 caret positons at a time how to hanlde this can you please suggest on this .
please find the sample code as below.

 if (ke.getKeyCode() == KeyEvent.VK_LEFT) {

            if (((JTextField) ke.getSource()).getCaretPosition() != 0) {
                ((JTextField) ke.getSource()).setCaretPosition(((JTextField) ke.getSource()).getCaretPosition() -1);
            }

        }

if this is not a bug please help me figure out how to manage it. 

I have written a small CellEditorListener which reacts on keystrokes. If I used it with:

setSurrendersFocusOnKeystroke(false);

it gets the keystroke-event, and on double mouse-click it looses the control (somehow).

if I used it with:

setSurrendersFocusOnKeystroke(true);

my Listener never gets the keystroke control.

I understand the differences with the carret, but which effects have the method 

setSurrendersFocusOnKeystroke(true) 

on the listener?

when start tying user would expect to replace the existing value, although JTable adds the typed text to the end. That would be nice to fix