Error and Tab key problem

If you want to track any other keys typed in the textfield - use KeyListener

KeyListener will allow you top analyze the input of any character in JtextFiekd and take any action you requre

ActionEvent is generic event - eeac element generate it on its most common function - such as enter for textfield. KeyEvent is more specific for tex componens and allow much moredetailed analysis and speific response for JtextField

What I mean is that on any of the fields when the enter key is press it does do from one field to the next whether it is blank or not.  Even demo programs..  This is what has been prohibiting my progress in event handling.

That is normal behavior. How does it oprhibit ?
In your event handler you just read text and if noithing is entered take appropriate action - usually say just return

The normal way to deal with mutitextfield form is to provide submit button and let the user to enter the fileds in any oirder he wants (using tabs or enters or anythng) and not listen to events from these textelements. After the user clicks the submit button yiu may analyze and if sone crucial texyfiled is lacking info or if the inpuit is wrong - raise the errror message

Isnt' is normal function for when you press the enter key on a text field to move from one field to the next.  Whilst with combo box and other components it is tab.

If this is normal for the tab key to do this in java instead of the enter key like other languages.  I would like to trigger if the tab key was press so that I can test what was entered.

Tab is normal everywhere especially on the web - and that becomes the standard

The reseaion I was testing what was entered is that I have to display infomation in the fields from a database as the user progress so as to avoid wrong data entry.  So I would then have to test for events witht he tab.  How do I do that?

What type of listener does that?  I already know how to write the event handling routine.  Is the tab key progressive testing that I have to get solve.

If you want ti trak in more detail yoiu can use keylistener as I mentioned aboive. For what you want maybe yoiu want rather to use FoicusLisrener and that will triger even when your textbox loses focus.
However, if this is not absolutely necesary I recommend not to do it but rather analluyeze the whole form as I mentioned above - focusListener and keylistener sometimes are difficult to debug
And if they are not well deb ugged they will cause probklems to the user.

That is the solution - focusListener.  Now if after I test and the data is invalid.  How do I set back focus to the component.

I tried the focuslistener and it works.  However, I am now unable to getText or getSelectedText as the focuslost method does not have these method.  So what should I do?

Thank you very much.  I tried the component.requestFocust() method and it works.  It sets back the focus and stays on that field.  However, I have the final problem.  I am now unable to getText or getSelectedText as the focuslost method does not have these method.  So what should I do?

I am so happy for this solution.  Now I can test when I lost focus from a component and If the data is invalid I can set back focus on that object.  I can not do a progressive test.  I just need to get the text entered and I am done.

I mean I can now do a progessive test which is what I wanted all along.

Everything works.  However, can you decipher what is wrong with focuslost method.  When I tested for the source it works. But when I test for the source and if the field is null it doesn't work.  The code seem correct.  

public void focusLost(FocusEvent e) {
	    	if(e.getSource()==tf1 && tf1.getText().equals(null)) {
				  System.out.println("This field cannot be blank");
				  tf1.requestFocus();
			  }

		  }

Select allOpen in new window

Problem solved.  it works.  You are good.  I will now close off this session and go and work.  Thank you very much for your time and patience.

I forgot to add.  This also solves the problem with auto-completion session that we were discussing in another session.  This focus listener was the solution all along.

well, let's hope it works fine for you
in my experiece it sometimes fires at the moments inconvenient for the user

Even though ithat happens.  It is only when the combobox loses focus is when the user has finish his selection, isn't it?  Therefore, that is when I shall test.

Well, sounds OK theoretically.
In practice I usually ended up going away from it.
It is all a matter of testing - and if it is convenient then fine; I usually had some situation which I didn't like - it generated some events
at unwanted times.