Name: rmT116609 Date: 04/15/2004


A DESCRIPTION OF THE REQUEST :
In 1.4 FocusEvent's were enhanced to add getOppositeComponent() but the InputVerifier and a VetoableChangeListener on the "focusOwner" property of the KeyboardFocusManager don't have any way of getting the "opposite component".

JUSTIFICATION :
Our system's business logic would like to edit fields when they loose focus. The InputVerifier would be the best way to do this, but for many edits we need to know the component that is about to get focus. (Useful when a series of fields that make up a primary key are being input and you want to prevent duplicates).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Could use InputVerifier to do all editing and thus never have to write code to put focus back to component in error AFTER some other component has gained focus.
ACTUAL -
Prior to 1.4 we had to do all editing at FocusGained after having saved the previous focusLost component. This was the only way to have all info needed to ensure unique keys. Thus if there is an edit error, we have to return focus to component that lost focus and inhibit editing for next FocusLost as we programmatically transfer focus.

This code has been a nightmare under 1.4 where we never know when requestFocus will really happen. Think we'd be much better off being able to use an InputVerifier and not have to worry about programmatically returning focus to component in error. But to do that we need to be able to get "opposite component" in InputVerifier.shouldYieldFocus().

Next best would be if a VetoableChangeListener on focusOwner could get the get opposite component.

CUSTOMER SUBMITTED WORKAROUND :
We continue to edit at FocusGained and return focus via requestFocus() to the component the previously lost focus.
While this approached worked under 1.3 JVM quite well, it's been not under the 1.4 new Focus system. We've spent hours and hours fixing subtle bugs related to editing/error focus problems all due to the focus going back and forth. Please supply a better API for apps that do serious editing.
(Incident Review ID: 232014)
======================================================================