Updating based on user editing value in JTextField

I have a Swing application. The top half uses a JTable to show a list of records. the bottom half shows details of the currently selected record as a series of JTextFields, this is correctly updated through use of a ListSelectionListener.

Now want a user to be able to edit a field in the bottom half and when they leave the (JTextField) field the record as shown in the datasheet should be updated to reflect the changes. I dont want them to have to press an Ok button. Ive looked at a few ways of doing this but none of them seem quite right, what is the correct way to do this?

First of all I tried adding a Document Listener to the documents returned by the JTextField, but the trouble was that I was unable to distinguish between a record changing due to a user edit and a record changing due to the user selecting another record in the table. Even if I could distinguish between the two I was receiving a load of events I wasn't interested in.

I then looked at using an ActionListener, but this only triggers when the user presses the Enter key, I want it to trigger when they tab out or use the Mouse to move the focus. Also the documentation seemed to imply using of ActionListeners for this sort of thing was the old way of doing things and was there to provide backwards compatability. I could use KeyListeners and FocusListeners as well but it all seems very low level.

I then read about InputVerifiers, as I understand it this would trap the user leaving a field they have edited. But arent they for validating input rather than what I want to do.

thanks Paul

[1609 byte] By [paultaylora] at [2007-11-27 8:02:06]
# 1

Well, if you don't do any editing of the data entered into the text field, then I would just use a FocusListener. (ie. a comment type field)

However, if you need to validate the input before saving it, then an InputVerifier is more appropriate, although I'm not sure it will work because I'm guessing that clicking on a different row in the table will cause the selection to change, even if focus is returned back to the text field.

It depends on your requirement. There are no other higher level API's that I can think of.

camickra at 2007-7-12 19:44:13 > top of Java-index,Desktop,Core GUI APIs...
# 2
I may want to validate input, so I was going to use an InputVerifier but I was nervous about updating the underlying model from the inputverifier.I think it is fine for the user to lose an edit of a currently focused field, if they click on another record - is that what your saying
paultaylora at 2007-7-12 19:44:13 > top of Java-index,Desktop,Core GUI APIs...
# 3

Normally the way an InputVerifier works is to reset focus on the component if it contains invalid data. That way it forces the use the fix the data before focus can move on to another field.

However, the problem I see in your case is that if you use an InputVerifier and enter invalid data, the when you click on a different row in the table, the input verifier will force focus back to the text field, but in the mean time a selection event will probably be fired (I'm guessing here) and your text field will be updated with data from the newly selected row. If this is in fact a problem, I'm not sure how to get around it.

camickra at 2007-7-12 19:44:13 > top of Java-index,Desktop,Core GUI APIs...
# 4

I don't think the case you describe is a problem, but having implemeneted the code there is another related problem.

The input verifier always returns true at the moment (it performs no input verification). If I start editing a field and then click on another record in the table, the detail panel gets updated with the values of the newly selected record. Except for the field I was editing in this has the value from the old record, in fact i dont even need to edit it, it justs need to have the focus. This problem doesn't occur if I don't add the InputVerifier.

paultaylora at 2007-7-12 19:44:13 > top of Java-index,Desktop,Core GUI APIs...
# 5
Try wrapping the code in your selection listener in a SwingUtilities.invokeLater(). This should allow the InputVerifier code to finish doing whatever it does before you attempt to repopulate the text fields with new data.
camickra at 2007-7-12 19:44:13 > top of Java-index,Desktop,Core GUI APIs...
# 6

Thanks the update code in the selectionlistener was already using invokeLater(), but both the selectionlistener and the inputverifier were sharing an int that held the row index, and selectionlistener was updating this variable outside of SwingUtilities. This was causing the problem Ive now replaced with a separate method variables.

So this works great, but my Inputverifier is updating the underlying data as fields are edited, is it ok for InputVerifier todo this it doesn't seem right. Or am I just getting hung up on the name, I suppose with most form processing you wouldn't commit changes to file until you clicked an OK button but that method is not required here.

paultaylora at 2007-7-12 19:44:13 > top of Java-index,Desktop,Core GUI APIs...
# 7

Thanks the update code in the selectionlistener was already using invokeLater(), but both the selectionlistener and the inputverifier were sharing an int that held the row index, and selectionlistener was updating this variable outside of SwingUtilities. This was causing the problem Ive now replaced with a separate method variables.

So this works great, but my Inputverifier is updating the underlying data as fields are edited, is it ok for InputVerifier todo this it doesn't seem right. Or am I just getting hung up on the name, I suppose with most form processing you wouldn't commit changes to file until you clicked an OK button but that method is not required here.

paultaylora at 2007-7-12 19:44:13 > top of Java-index,Desktop,Core GUI APIs...