Steps to reproduce:
- run IDE
- opens some java file
- try to invoke Find dialog , press Ctrl + F
-> Find dilalog comes up, but focus is on the main
P2: it's really very annoying, if you must after
pressing Ctrl+F, click to find dilaog by mouse ....
*** Issue 34527 has been marked as a duplicate of this issue. ***
*** Issue 34891 has been marked as a duplicate of this issue. ***
FWIW, this has happened to me a number of times (Linux JDK 1.4.2), but
I cannot reproduce it now. May be specific to the window manager.
It used to work this way:
If you use SDI, the find window's parent is set to main window, which
causes the focus to return to main window instead of editor window.
I never had problems in MDI (only one window which remembers focus
Maybe it has changed from that time...
I always use MDI.
I tried reproduce this issue, but it is reproducible only on Mac OS or
SunOS+CDE+focus follow mouse. It seems this issue is not defect on
SunOS, because other applications e.g. native Text Editor in CDE has
the same problem with focus (after ctrl+F).
It is 100% reproducible on Mac OS 10.2.6, IDE 3.5.1, jdk1.4.1_01.
So IIRC in SDI if WM decides to focus the parent of the dialog (once
the dialog gets closed) we have no chance to override its decision by
explicit editorPaneOrFrame.requestFocus(), right?
On the other in MDI I would believe it should be possible to redirect
the focus from main window to editor pane because they should reside
in one physical frame, right? Unless of course the customized swing
release for Mac does not do something special here :)
Anyway we should resolve this for 3.6. Assigning to Dusan.
Hasn't happened to me in a long time on Linux, I think; probably
specific to the window manager.
Maybe Tim has some suggestions for handling focus changes.
This may be 1.4.1 specific (on mac it almost never gets focus) - I know there were
some changes between 1.4.0 and 1.4.1 and 1.4.2 re focus (see some of the gnarly
requestFocusFor14() code in NbPresenter, I believe).
So at least on the mac, it's definitely still an infuriating problem. I've checked over the
code for the find dialog in the editor, and it looks like it's doing the right thing if what
I think is being called gets called (inasmuch as I understand it - there's some method
called updateFocus() that tries to call requestFocus() on "updateWhat" - it's tough to
figure out what does what with so many layers of dialog provider services, button
provider services, etc.)
(findWhat is the combo control with text to search)
That should likely happen by default anyway but IMHO it should not harm.
BTW what about other non-modal dialogs on Mac like e.g.
Tools->Options. Do they also fail to get focus?
Actually, closer to home, the Goto dialog is always focused correctly.
Might be a problem of the FocusTraversalPolicy in the find
dialog...but what's a little odd is that about 1 out of 5 times the
text field does get focus.
We might try a FocusTraversalPolicy that always returns the find combo
as the thing to focus, then see if the problem goes away - it would at
least help diagnose what's wrong. At the same time, if it isn't, it
could turn out to be a waste of time.
Fixed in [maintrunk].
/cvs/editor/libsrc/org/netbeans/editor/ext/ExtKit.java,v <-- ExtKit.java
new revision: 1.39; previous revision: 1.38
new revision: 1.36; previous revision: 1.35
verified in [nb_dev](200402221900)