This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
A strange problem cropped up here at work... it has been solved, so no-one should feel pressured to fix it... I was just wondering if anyone else had experienced it, or knew why it was happening, or to help someone out with the solution if it happens to them. A friend of mine here at work was working on validating dates in JTextFields ( which threads here on JavaRanch helped out mightily on! )... He was using a FocusListener to listen for FocusLost to run the validation. He started developing his code on a Windows NT machine and it was working fine, he then move it to a Solaris machine. Everything worked fine, except when arrow keys are pressed in the JTextField, a FocusLost event is thrown and the data in the text field is re-validated, effectively forcing the caret to the end of the text any time an arrow key is pressed anywhere in the program. I tried to figure out what event was being thrown, so I printed out the event being thrown. I noticed that a temporary FocusLost was being thrown when the arrows were pressed, so we added a test to ignore any FocusEvent when isTemporary() returns true. It seemed to work great, so we went back and tested it on Windows... it seems that Windows does not throw a temporary FocusLost event when arrows are pressed in JTextFields, but Solaris does. I would expect this kind of thing from the AWT, but I thought that Swing was supposed to remove platform dependent behavior like this from GUI programming! The only reason that I can come up with is that FocusListener is in the AWT (java.awt.event), so some old platform dependent code may still be in there... -Nate
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
We were doing development work and our target platform was a device called "Clio". When our program worked fine on our NT development boxes, and appeared to not work at all on the Clio, we eventually discovered that Clio would throw the mousePressed and mouseReleased, but would fail to fire the mouseClicked.