JTable: auto edit cells and ENTER=next cell

In coding everything is possible, but I think you have a hard job to do.
Good luck.

Don't think you can use JTable for that, instead you want to create a grid of JTextField's (or whatever is appropriate).

Actually, in JDK1.3 we have it working. However Sun rewrote the whole Focus handling in JDK1.4 and I'm not in the mood to figure it all out again. Appearantly I have to. ;-)

"A grid of" I also considered, but it means I have to write columnheaders, sorting, column scaling using the mouse, column dragging, etc, etc. Ahhhh. I'l stick JTable for now.

sorry I read your q wrong, I thought you wanted *all* cells to always be in edit mode.
Just ignore me :)

He he, ok, but all cells in edit mode would be quite useless, since I only have one mouse pointer and one cursor... ;-)

i did think it strange at the time :)

For those who are interested: a half way update.

The two lines below enable ENTER as "next cell" (from within a class that inherits JTable).
  getInputMap().put( KeyStroke.getKeyStroke("ENTER"), "selectNextColumnCell");      
  getInputMap().put( KeyStroke.getKeyStroke("shift ENTER"), "selectPreviousColumnCell");

Secondly, overriding editingStopped and editingCancelled is a way to edit another cell. Remember the edited position before super and call editCellAt afterwards. Using the focus (either via a listener or via processFocusEvent) is not, because for some reason nomore focus events are triggered, if editCellAt is called from there.

So far so good. Now I have the strange behaviour that appearantly there is something like a "focused cell" (white in the blue selected line) and the "edited cell". These two appear to be not the same: I can have one cell "focused" while editing another cell. Oh jolly.

To be continued...

Getting closer.

Registered the JTable extention as a keylistener on the editors. Remembering the last pressed key and upon editingStopped/Cancelled, mapping that key to the InputMap and use that to determe the next cell to be edited (next or previous). Works okay for a specialized Integer editor and color editor. Also enhanced the DefaultCellEditor with code to do a SelectAll upon entry.

So I'm pretty close, the only thing that keeps bothering me is the "focused" cell. It kinda goes AWAL. I disallowed row, col and cell selection, so it's not so visible, but the small frame often drags a few cells behind the edited cell. What is it with that focused cell? When I'm editing, it should be the same cell! What is JTable thinking?

The fastest way, is to let your class extend from FTable instead of JTable.
Just try it.
I solved another anoying JTable problem this way.

Interesting class. I'll examine the code closer.

But no, that does not fix it. I found the circumstance (not the cause) for the problem: when I hit a not-editable cell in my "determine next cell" algorithm, I just call the algorithm again and it will skip that cell. However, the focused cell does not skip over the not-editable cell. As of then, it lags one behind. In the next line it happens again and it will lag two cells. Vice versa, upon shift-enter the lag is shortend by one.

If I deactivate the "force selection" code in editCellAt, the same behaviour persists. So the reason why the focused cell and the edited cell are running along at first, is because I have set the inputmap (see above) to do so upon an enter. When the not-editable cell is reached, the edited cell skips but the focused cell does not. Hence: the "force selection" code is not having any influence.

>>But no, that does not fix it.
I would have bet it would fix it.
Sorry :°(

Inheriting FTable ALMOST solved it. The lagging behind is indeed gone. However, I actually need to be able to select a row to zoom/delete it (like MSAccess). But if I reactivate "allowRowSelection" the selected row goes AWAL. I'm considering writing a row selector (like MSAccess ;-)

Almost. Almost.

Thanks!

>> The lagging behind is indeed gone.
Oh... Good!
>>I would have bet it would fix it.
Bet won :°)

>>But if I reactivate "allowRowSelection" the selected row goes AWAL.
That means?

AWAL. Absent Without Authorized Leave. A US military abbriviation. Which means as much as going we're you're not supposed to be.

Here it means that when I enter over the checkbox editor and the Color editor (which happen to be next to each other) the selected line suddenly moves down. So for the first few cells, the first line is the selected line, but then when editing column 5 (line 1), the second line becomes selected, and then when editing column 6 (line 1), line 3 is selected. After that the selected lines snaps back. I suspect it has to do with the editor in place. All the other cells have text based editors...

Well. A workaround. In edit mode I deactivate selection, so the presentation looks ok. When editing is cancelled, I do not re-enter editing and reactivate selection. When editing is stopped, I edit the next cell.

Seems to work so far.

>>In edit mode I deactivate selection ... When editing is cancelled ... reactivate selection
Rather straightforward.

>>Seems to work so far.
Nice

Shoot.

Although the trick makes it look ok, the focused cell/line is still moving down, it's just not visible. It becomes obvious when the scrollpane scrolls the edited cell out of view!

Back to the drawingboard.

:°(

>>I think you have a hard job to do
Another bet won. ;°)

>>the scrollpane scrolls the edited cell out of view!
Just an idea to "solve" this:

add

      scrollRectToVisible(getCellRect(row, column, true));

in your editCellAt() function

This is the situation:
- as soon as a non text editor is used
- after entering out of the editor
- the focused line moves one down (or up when doing a shift enter)

I can force the focus back to the cell in the processKeyStroke method, but the focus still moves. This means that in the last line and in the first line the table is jumping (wrapping).

I'm able to get the focus back in line when I force it back to the editing cell in the processKeyStroke method. It still steps out one line, but then right back in... Now I have a conflict when using the mouse. Sigh. You indeed won the "hard job" bet...

Well. Who would have thought that? It actually works. With some minor presentation quircks that one has to take for granted, I actually have a JTableForEdit. Wrote it as a generic component, so it can (almost) be used as a dropin replacement. Almost, because currently I'm extending the TableModel to TableModelForEdit to incorporate automatically adding and deleting of rows.

HA!

If anyone has a suggestion how I can get the cell focus better in grip, please do tell. And I was amazed that the FocusLost event on the editor comes AFTER a new cell is edited. I expected editingStopped/Cancelled to pull the focus back to the table and editCellAt pushing it back to another editor. The focus handling in Java still (1.4+) is weird.

>> It actually works.
Great job!

>>If anyone has a suggestion how I can get the cell focus better in grip, please do tell.
I'm afraid that "anyone" is rather restricted...
A new Q would probably "attract" more experts.

Thanks for accepting.
I see it as an appreciation of my (in this case small) efforts. Really appreciate that.
Sorry I couldn't help you more.
Just for my interest: do you use that FTable or did you just pick up some ideas?

No, I use FTable, because it keeps the focus controllable. That is the reason why you got the points (although 500 is a bit overpaid, I agree ;-) and because I hate it that I mostly seem to be solving my problems myself (where do I have all these experts points for, if I can give 'em away?).

A new question is not needed, but I expect visitors on this question... Hehe.