JDK-4493590 : would like an API to discover the reason for focus_gained
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2001-08-18
  • Updated: 2008-05-14
Related Reports
Duplicate :  
JDK-4392097 - Would like ability to determine why focus gained
Relates :  
JDK-4931668 - Need to implement server side support for XEmbed
Relates :  
JDK-4912629 - JFileChooser TextField text does not get selected when tabbed in unlike Native
Description
Name: mt13159			Date: 08/17/2001


It would be useful to be able to tell why a component received focus
whether it was from keyboard navigation or some other means.  Specifically
Oracle has implemented its own widget set.  That widget set includes
a simple text field.  We would like to select all the text when
the user tabs into the text field.  We do not want to select all
the text when the user clicks in the text field.  The Swing JTextField
has the same requirement.  Right now tab into a JTextField
and all the text gets selected.  Click into a JTextField and all
the text gets selected for a moment until the cursor moves to the
mouse point.  Adding an API on FocusEvent would make it extremely
easy to determing if focus was received due to a keyboard navigation
event or some other call to requestFocus().
(Review ID: 128544) 
======================================================================
Comments
EVALUATION for more complete explanation of the problem I've tried to describe in my previous evaluation see 6378278
28-02-2006
EVALUATION To implement this rfe we need to add new methods of requestFocus family with additional parameter (cause) and start to use them. But to keep backward-compatibility these new methods will need to call old versions of requestFocus* methods and pass additionale parameter to internal helper method using Component's member (it should be ThreadLocal since requestFocus could be called on any thread) But this scheme will not work for nested calls. E.g.: we call requestFocus(Cause X), it sets field to X and calls requestFocus() inside requestFocus() someone (e.g. InputVerifier) calls another requestFocus() which in turn will call requestFocusHelper() and the halper will think that the latter focus transfer has reason X (WRONG) So, we can not implement this request in backward-compatible change :( Leave it open with hope that someone will approve such change.
26-02-2006
WORK AROUND Name: mt13159 Date: 08/17/2001 Oracle and JTextField could add a boolean flag when the mouse is clicked that says the next focus gained event was not from the keyboard but it is a hacky way to do it. ====================================================================== Problem with this approach is that any time a developer invokes requestsFocus we would end up selecting all the text, which isn't right. ###@###.### 2003-10-07
07-10-2003
EVALUATION Name: osR10079 Date: 04/28/2003 Currently we create focus events mostly based on the native events. Native platforms (at the very least Windows) do not provide any means to determine the reason of focus event. We are investigating possible heuristics that would allow us to guess, but we cannot guarantee this functionality in tiger. ###@###.### 2003-04-28 ====================================================================== ###@###.### 2005-04-08 17:12:40 GMT
28-04-2003