Determine which JTextField is having something entered into it

[simon fletcher]

I have a few JTextFields in a JPanel. Some checks have to be done as a user types things in. The thing I can't seem to figure out is which listener to use in order to determine which textField is having data entered into it. I've looked at FocusListener, KeyListener, ActionListener, ComponentListener but none of their methods seemed to do this. ActionListener is useful if a person presses enter, as it fires an action event, but that's not good enough as I want to check what the user's typing in with each press of a keyboard button.

I've thought of a few ways to deal with this (the obvious being individual key listeners added to each text field with a call, within its key pressed method, to a method that does the checking) but, if I wanted to implement a listener to the class and have one whatever-performed method that calls a method with a switch that uses the identity of the text field that is being edited in order to determine checks on the data entered, which listener is appropriate and which method returns something that identifies the text field that is currently being used?

Thanks in advance.

[Maneesh Godbole]

simon fletcher wrote:Some checks have to be done as a user types things in. The thing I can't seem to figure out is which listener to use in order to determine which textField is having data entered into it.

You need to use a DocumentListener Recommended reading: http://docs.oracle.com/javase/tutorial/uiswing/events/documentlistener.html

[simon fletcher]

I had no idea about this. I came up with some other ways of "dealing" with my problem but none of them were very elegant. This looks like it should do it. Thanks.

[Campbell Ritchie]

Whichever listener you use check that it does not perform its action until the entering is complete. You want Simon to be one event, not five: one for each of the letters.
Some text components support action listeners, fired if the user uses the enter key.

[simon fletcher]

All advice noted. I will try several approaches and post what works. Thanks.

My goal with this is to check that, when user is entering long integer values into each of several text fields, if they miss-key (like press R instead of 5) the program will pop up a notice (and possibly beep for those who keyboard-gaze when inputting data) saying they entered an invalid (non integer) entry right away. This would be followed by having the invalid character they entered selected in the textfield so they can see what they entered incorrectly and just start typing right over it. I thought this would be pretty easy to do, and possibly it is, but I haven't been successful yet. My code, which seemed to get me close to this but never quite there was becoming convoluted and giving some unwanted results.

[Rob Camick]

Some checks have to be done as a user types things in.

You should be using a DocumentFilter. Then you can just "beep" and prevent the character from being saved in the Document. See the section from the Swing tutorial on Implementing a Document Filter for a simple example. Another option is to use a JFormattedTextField. The tutorial also has an example for this.

A DocumentListener is used for doing processing AFTER the Document has been updated.

[simon fletcher]

Thanks again for all the guidance. I never would have guessed that a few little textfields would be the cause of such a huge amount of eye-strain (from so much reading). The little beasts are more complex than they first appear. I guess that particular common theme, throughout Java (and probably programming in general), is what makes it so much "fun" to learn.

EDIT:

I finally got it to work. I ended up with the same problem that half the internet seems to have which is that my computer will not beep. I tried everything except running it on another machine but to no avail. Oh well. The rest works. I'll post the relevant code soon and if anyone would like to point out any alternate or better ways, that's fine by me. There are always alternate ways, it seems, when it comes to Jave. There are bound to be better ways, considering I'm still relatively new at it (and having trouble with such basic things).