 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / September 2006focusLost vs. actionPerformed
I have a number of JTextField components that allow user entry. I have set up both an ActionListener and a FocusListener so that, for either actionPerformed or focusLost, the value is examined for validity. If it is invalid, a message dialog is put up indicating the unacceptable entry. I leave the user input in the JTextField while the message dialog is up to allow the user to mentally acknowledge the error, but replace the old input value when the message dialog is done. However, if the bad input is via actionPerformed, acknowledging the message dialog seems to cause a loss of focus. On at least my machine, the focusLost process is started before completion of the actionPerformed process. As a result, as the bad value is still in the input field, the message dialog comes up again. Is this something that can be counted upon (ignoring focusLost while actionPerformed is running), or do I need to take some kind of additional precautions? >I have a number of JTextField components that allow user entry. > I have set up both an ActionListener and a FocusListener so that, [quoted text clipped - 15 lines] > while actionPerformed is running), or do I need to take some kind > of additional precautions? Popping a error/warning dialog on FocusLost is usually a *bad idea*. The problem is that the user starts entering the info, then realizes she has to look elsewhere to view information necessary to input the correct info. But when she tries that, bang! - you force thiis dialog up, she acknowledges it, and you send focus back to the offending text field. Then she tries to go elsewhere to find the info, and you pop up the dialog again. She in frustration then abandons anything to do with that program.  SignatureFred L. Kleinschmidt Boeing Associate Technical Fellow Technical Architect, Software Reuse Project > "Richard F.L.R.Snashall" <rflrs@notnotrcn.com> wrote in message > Popping a error/warning dialog on FocusLost is usually a *bad idea*. > The problem is that the user starts entering the info, then realizes she [quoted text clipped - 4 lines] > the dialog again. She in frustration then abandons anything to do with > that program. In its present state, I do not force the focus back to the offending component. I basicly ignore the bad input by putting the good value back. This does not allow the user to just edit it to a good value, but it does preclude the problem above. However, if I don't check the input when focus is lost, (or do you have an alternative), it could sit there in a poor state with no message to the user. Wouldn't that be just as poor? That still leaves the original question. Is it a property of my machine that the loss of focus is acted upon before the other actionPerformed process has completed, or would that happen on all platforms? >> "Richard F.L.R.Snashall" <rflrs@notnotrcn.com> wrote in message > [quoted text clipped - 16 lines] > have an alternative), it could sit there in a poor state with no > message to the user. Wouldn't that be just as poor? Say, for example you have 5 text fields and an OK button. The actionPerformed of the button then checks all fields and either performs whatever is supposed to happen (if all is OK), or reports all errors. I really dislike it when an error dialog pops up due to a focus lost event. What if I am entering info and I notice that I have received an important email? I go to read it and - bam! - here comes this stupid dialog. > That still leaves the original question. Is it a property of my > machine that the loss of focus is acted upon before the other > actionPerformed process has completed, or would that happen on all > platforms? When you press the acknowledge button on the dialog, this happens: 1)The item that had focus gets a focus lost (unless it was this button). 2)The button gets a focus gained (if it didn't already have it) 3) The button redraws itself as pushed Then when you release the button, 4) actionPerformed 5) the button redraws itself in its un-pushed state Actually, there are several other events happening, too (mouse motion, leave, enter, etc.) SignatureFred L. Kleinschmidt Boeing Associate Technical Fellow Technical Architect, Software Reuse Project > In its present state, I do not force the focus back to the offending > component. I basicly ignore the bad input by putting the good value > back. Arghhhh. I would go mad if an application does this to me. Actually, I would avoid the application in the future on the fear that there is more wrong with it than just a broken input window. Imagine you are typing in a word like pneumonoultramicroscopicsilicovolcanoconiosis. And you are not sure if it is actually ...coniosis or ...koniosis at the end. So you typed the word, and just want to do a quick check on the web if it is c or k in coniosis. And bang, right before you are done with entering the data the application deletes the input and replaces it with "good" values. THANK YOU VERY MUCH. Or even worse. Imagine you are, for whatever reason, distracted during input and accidentally move the mouse outside of the window. Or someone bumps against your table and the mouse gets accidentally moved. > That still leaves the original question. Is it a property of my > machine that the loss of focus is acted upon before the other > actionPerformed process has completed, or would that happen on all > platforms? It does not matter. a) Your handling of the data is anyhow faulty b) If it happens you your machine it is likely that it happens on many more machines. /Thomas SignatureThe comp.lang.java.gui FAQ: http://gd.tuwien.ac.at/faqs/faqs-hierarchy/comp/comp.lang.java.gui/ ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq >> In its present state, I do not force the focus back to the offending >> component. > Or even worse. Imagine you are, for whatever reason, distracted during > input and accidentally move the mouse outside of the window. Or someone > bumps against your table and the mouse gets accidentally moved. That could happen whatever the state of the input. Since the input here is numeric, the odds are that what was already typed in is valid. Tell the kitty to get off the table;-) >> That still leaves the original question. Is it a property of my >> machine that the loss of focus is acted upon before the other [quoted text clipped - 4 lines] > > a) Your handling of the data is anyhow faulty Actually, it is based upon existing tools, where losing focus caused whatever data was in the field to be accepted. What I objected to in those tools was not that it accepted the input, but that it would accept up to the first error and quietly ignore typing errors. > b) If it happens you your machine it is likely that it happens on many > more machines. Is it a property of the Java environment or of the individual platform? > I have a number of JTextField components that allow user entry. > I have set up both an ActionListener and a FocusListener so that, > for either actionPerformed or focusLost, the value is examined > for validity. [...] I provide an open source Java library for validation. There's a Validation Demo that demonstrates a bunch of problems, concepts and solutions for Swing validations and validation presentations. The JGoodies Validation project is here: https://validation.dev.java.net The JGoodies Validation Demo is here: http://www.jgoodies.com/freeware/validationdemo/index.html -Karsten Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.