It happens quite often to me that when I open a dialog window (it happens to me
in various dialog windows) and try to write some keys into single-line text
field (it displays caret in it so I do not use mouse to set focus to the field)
they don't display. I have found out that if I click with mouse to another text
control, the output of the buffer holding the keys is flushed into the text
field I set focus to.
I use 200511221900 daily build but it happens to me since the time I begun to
use nb (about 2 weeks) so I cannot tell whether it behaved some other way before.
Could you be more specific? Please write a list of dialogs, where you can
encounter this problem. Also please add your JDK version. Thanks in advance.
Sorry for incompletness. Here is a simple procedure:
1) create property resource file and add some locales (I have en and cs)
2) open the resource file for editing in tabular view (not source)
3) press New Property a start input some characters (if it works the first time
- it did right now when I try it - then just close the dialog and press New
4) when no input displays though you pressed some keys, click mouse to Value or
Comment field - buffered characters should be flushed into the field you clicked
(if you press Esc during "hidden input" period, the click to another field
causes closing of the dialog)
I remember this also happened when I was adding new library through Library
Manager (Project pane -> Libraries -> Properties -> Add Library -> Manage
Libraries -> New Library -> try input)
I have tested these both dialogs to be sure the bug occurs (it did). There might
be more dialogs that suffer with this problem but I'm not sure where else it
My JDK is "Sun JDK 1.5.0.05".
Marian could you please try to reproduce on Linux? I smell another JDK bug due
to the nature of occurence, so please try to test both jdk 1.5 and mustang, it
may even be already fixed on JDK side.
Also jtulach, I remember you were dealign with similar issue long time ago?
Btw, this issue is very similar to 60656, although reproduction steps differ.
*** This issue has been marked as a duplicate of 50423 ***
It looks like it's really the JDK bug. It's also marked as fixed for Mustang
(build 53). SO if you want, wait for the build or try to use:
-Dnetbeans.hack.50423=true to enable reflection based workaround
for the type ahead problem