1

I am having the following issue: I have a JTable with its on tablemodel sitting on a JFrame. The tablemodel is backed up with an own hashmap to store the contents. The table has two columns where the right one is editable.

Normally the user changes some value on the right then presses the enter button which fires the tabledatachanged event that calls my saving function. Then the frame can be closed.

However, some users just simply edit the cell and then they close the window without pressing enter so I get no chance to save the table. I know how to write events when the frame is about to be closed, but I do not know how to retrieve the content of the "unfinished" editing while also finalizing that edit.

I guess it has something to do with the celleditors, I even tried with the table.getCellEditor() that should return the active one but instead it returns null.

Thanks for the help!

mKorbel
  • 109,525
  • 20
  • 134
  • 319
GooKSL
  • 387
  • 2
  • 14
  • 1
    I'm lost, what, where, how, please ??? – mKorbel Oct 15 '12 at 13:34
  • issue is CellEditor, Window, or their interacion – mKorbel Oct 15 '12 at 13:35
  • 2
    try table.putClientProperty("terminateEditOnFocusLost") If that doesn'nt help, show an SSCCE that demonstrates the problem – kleopatra Oct 15 '12 at 13:38
  • the issue is that I want my saving method to run when a button is pressed/window is closed BUT there is an unfinished editing in a cell. I dont know how to express it properly, sorry – GooKSL Oct 15 '12 at 13:38
  • @kleopatra I have wrong experiences with `terminateE...` for `AbstractTableModel` based on `ZOO` (`HashMap` e.i.), for DefaultTableModel works, strange (EDIT sure fireXxxXxx are sets properly :-) – mKorbel Oct 15 '12 at 13:41
  • @kleopatra thank you, this works like a charm! Ok, please post it as an answer so I can accept it. BTW, how am I supposed to know this? Looks like a hack... – GooKSL Oct 15 '12 at 13:44
  • it's a looong story (forgot the long-standing feature/bug issue in the bugparade). Short version: a) the current default behaviour is what the original developers thought to be the correct and only b) after years of hefty debates from real-world developer, the swing team conceded that there _miiight_ be a real-world contexts that would need some kind of auto-termination c) after more years one of them was allowed to really listen and implemented the CellEditorRemover, temporarily by client property because the api was frozen between releases d) ... nothing more :-) – kleopatra Oct 15 '12 at 14:21
  • ... and no way to know/learn it except reading the source code (and/or asking and hope some of the elder folks might listen :-) – kleopatra Oct 15 '12 at 14:22
  • thanks, very interesting story :) – GooKSL Oct 15 '12 at 14:29

1 Answers1

6

The most simple measure is to configure the table to do its best effort when loosing focus:

table.putClientProperty("terminateEditOnFocusLost", Boolean.TRUE);

Unfortunately, there are contexts when its best effort is not good enough (f.i. when the user clicks the close button of a frame). In those, there is no way but to hook into each and every lane that might loose the edit and manually force the edit to stop

if (table.isEditing()) {
    boolean stopped = table.getCellEditor().stopCellEditing();
    if (!stopped) {
        // here goes error handling and/or cancelling the edit
    }
}

From your description of the problem,

some users just simply edit the cell and then they close the window without pressing enter

I'm slightly surprised the the first is working, would have expected that you needed doing the second in a WindowListener.

See also Rob's blog entry

kleopatra
  • 51,061
  • 28
  • 99
  • 211