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
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
Created attachment 12563 [details]
Stack traces from java.awt.Component.requestFocusHelper()
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
I mean the helper popup JTextField that pops up if you just type in
Explorer and helps to find a node name you typed.
This may be a duplicate of issue 37995.
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.
Fixed in [trunk]
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.
verified in [nb_dev](200402221900)