Bug 38080 - Winsys sets focus to wrong component
Winsys sets focus to wrong component
Product: platform
Classification: Unclassified
Component: Window System
PC Windows XP
: P2 (vote)
: 3.x
Assigned To: Peter Zavadsky
Depends on:
  Show dependency treegraph
Reported: 2003-12-13 23:09 UTC by _ tboudreau
Modified: 2008-12-22 19:53 UTC (History)
0 users

See Also:
Issue Type: DEFECT

Stack traces from java.awt.Component.requestFocusHelper() (5.18 KB, text/plain)
2003-12-13 23:09 UTC, _ tboudreau

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2003-12-13 23:09:13 UTC
I noticed a strange thing with today's build - 
if focus is in the editor or Explorer, and I 
click on the property sheet, the following 

 - The property sheet gets focus
 - The Properties title bar turns blue to 
    indicate the component
 - Focus is immediately shifted back to the 
    editor or Explorer

So I end up with the property sheet being the 
activated top component and focus in the editor.
Clicking on the property sheet a second time 
works (I guess because winsys already thinks 
it's activated).

I dug through the PropertySheet code, commenting 
things out, and found it wasn't my problem.  
Finally I patched java.awt.Component to log 
calls to requestFocus().  The following line is 
calling requestFocus() on the component that had 
focus *before* the property sheet:


I will attach the log from the patched Component 
Comment 1 _ tboudreau 2003-12-13 23:09:50 UTC
Created attachment 12563 [details]
Stack traces from java.awt.Component.requestFocusHelper()
Comment 2 _ tboudreau 2003-12-14 00:14:10 UTC
Possibly related - the popup text box in explorer is also not 
working correctly - start to type and one character goes to it, then 
it disappears...most of the time.  Sometimes after repeated clicking 
it works.
Comment 3 _ tboudreau 2003-12-14 00:14:55 UTC
I mean the helper popup JTextField that pops up if you just type in 
Explorer and helps to find a node name you typed.
Comment 4 _ tboudreau 2003-12-14 00:16:42 UTC
This may be a duplicate of issue 37995.
Comment 5 Peter Zavadsky 2003-12-15 09:13:47 UTC
Yes, the stack from requestFocusHelper, points to the same cause like
I came in issue #37995 (ViewHierarchy.udpateViewHierarchy). I hope it
is same. Now it seems I can remove that hack thank to fix of issue

But first I'm going to check that.
Comment 6 Peter Zavadsky 2003-12-15 14:39:01 UTC
Fixed in [trunk]

core/windows/../view/ViewHierarchy.java 1.8
                    /ui/MainWindow.java 1.7

Note: This doesn't fix the other issue. 

The problem of this was a hack which preserved focus in view GUI
hierarchy..., there is a case when some component has focus, and is
removed/added back, because its parent split is removing due to a
sibling close), the focus is lost, thus needs to be restored.

Originaly the hack was too aggressive it restored the focus in all
cases, now it does it only in the above described case, which excludes
all cases like this issue describes.
Comment 7 Marian Mirilovic 2004-02-24 16:54:50 UTC
verified in [nb_dev](200402221900)

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo