Originally posted by Chantal Ackermann:
I don't understand how a focusLost event on a textfield can trigger the appearance or disappearance of other ui components - logically. does this really make sense? should the appearance/disappearance of these components not depend on the _value_ of the field? a documentlistener or keylistener would be more appropriate in that case.
or you want to leave it to the user to decide when he/she is finished entering a value in the field. an actionlistener would be sufficient in that case.
maybe it would help if you could explain why you want to listen to a focusevent in the first place.
(as a FocusEvent is a lowlevel event and thus gets fired more often than document or action events which already implement some basic ui logic).
Chantal
Originally posted by Paul Stevens:
The order of the events is not set. It just happens that that is the last event that is processed. It decided to do the event from the menu first.
Originally posted by Chantal Ackermann:
sorry, I'm a little slow... :roll:
does the component disappear forever (for the rest of the runtime) or does it appear again at some later point. in the latter case, I'd use CardLayout. The component wouldn't be removed but made invisible. thus, you wouldn't have to recreate it at some later time, but rather reuse it (performance). Moreover, I think the GUI would be "more aware" that the component isn't visible anymore and would set the focus to another one. And even if this wouldn't work - no NullPointerException should be thrown, and you could request focus for the component you wish to.
Chantal