Submitted On 23-JAN-1999
dcebula
I defined the accelerator sequence using registerKeyboardAction(). The invoked
action listener makes the text component un-editable and sets a Timer to change
the field back to editable. The desired method is then called. This sets up a
potential race condition, but I haven't encountered problems with it yet.
Submitted On 22-FEB-1999
alan griffiths
Note that there are similar problems with
JTextField and Action buttons. (see
<A href=4200559.html>4200559</A>
- which is closed as a dup of this.)
Submitted On 25-FEB-1999
RickN
This makes setting mnemonics for the menus rather
destructive. The problem that I have with making
the textfield uneditable is that this moves the
focus to another component (Possibly a text field).
I had better luck with putting a KeyListener on
the Jframe & doing a gratuitous "fileMenu.doClick()"
as soon as the VK_ALT key is pressed. This gives
an almost normal look & feel.
Submitted On 12-MAY-1999
jmrozak
***This workaround is also posted in
bugs 4186905 and 4200559***
When working with JDK 1.2.0 under Win95/NT I've
noticed this in JTextField as well, that Alt+x
inserts an 'x' into the field in addition to
processing the Alt+x combo.
I have a workaround for this, and have added it
to my 'SwingText' package of Open Java Source
components, found at:
http://www.enteract.com/~goose/java/swingtext
The workaround goes like this:
1) Establish an object-wide flag like "altIsDown".
2) in keyPressed(), if the Alt key is pressed,
set (altIsDown = true).
3) in processInputMethodEvent(), only if the
Alt key is NOT pressed, forward the event
to its parent. Then clear the flag:
if(! altIsDown) super.processInputMethodEvent();
altIsDown = false;
In my environment, at least, mnemonic key handling
still works OK when using this workaround.
Care must be taken to re-enable the field
during Alt-Tab, dialog popups, etc. Note
that putting the (altIsDown = false) in the
processInputMethodEvent() handler is easier than
trying to reset it in keyReleased(), focusGained(),
etc.
Submitted On 30-MAY-1999
jgkarol
This one still seems to be around on Win32 platform with new JDK 1.2.2. Oddly
enough, the other night I tinkered with the separate Swing 1.1.1 beta 2 (I
think it was), which offered EXE compiled versions of the Swing demos. When I
ran the SwingSet compiled, it worked fine (in other words, menu accelerator
keypresses weren't echoed to the text boxes), and yet when I installed the new
JDK 1.2.2, it looks as though they are back again.
Looks like it may be time to go back to mnemonic-less menus again. :-)
Submitted On 15-JUN-1999
spestov
It says that it's fixed in a `non-public release'.
What does this mean? When will it appear in a
mainstream JDK version? It is a very major problem.
Submitted On 21-JUN-1999
MiguelM
This is still a problem in JDK 1.2.2RC
Submitted On 15-JUL-1999
larryhy
This is still a bug in JDK 1.2.2 and I agree with spestov in that it is a VERY
MAJOR problem. Do you realize that there are many people who "fly around
products" using the keyboard only? For those people, and for ANYONE who
uses the keyboard, this bug is UNACCEPTABLE.
Do you also realize that this bug causes user's filenames to be renamed? Yup.
If you fire up FileChooserSaveAs dialog box, enter "myfile" as the
name and then hit "Alt-s" for "Save" the file that gets
saved is "myfiles". This stinks should be fixed immediately!
Submitted On 09-SEP-1999
IFC
I have faced this problem with JTextArea. I am using JDK1.2.2. One workaround
is to trap Key pressed event and when alt key is a modifier for the KeyEvent
then focus can be shifted to any component other than JTextArea temporarily.
This bug should be fixed.
Submitted On 11-OCT-1999
pjknowles
I would like to vote for this bug to be fixed, but I cannot, because the system
says that
it is fixed. As it is quite clearly not fixed in the JDK1.2.2 release, how
about setting the
status of this bug to open again to allow the various people to whom it is
causing
problems to cast their vote appropriately.
Submitted On 11-OCT-1999
pjknowles
Having included the above comment requesting the re-opening of this
bug, I thought I should include my reason for refuting Sun's claim that this
is a problem with the native awt
Sun JDK1.8.8 with Swing-1.1.1 - works OK
IBM JDK1.8.8 with Swing-1.1.1 - works OK
MSVM Version 5.00.3182 with Swing-1.1.1 - works OK
Sun JDK1.2.2 with built-in Swing (Whatever version that is!) - fails
Sun JDK1.2.2 with Swing-1.1.1 set thru -Xbootclasspath - works OK
So unless Sun have managed to break the AWT in JDK1.2.2 the problem appears
to be with the Swing implementation shipped in the 1.2.2 package, hence my
request to re-open this bug for votes
Submitted On 21-FEB-2001
garybiagioni
<BR>
Submitted On 21-FEB-2001
garybiagioni
In response to jmrozak
Thanks for placing your workaround on the web for the ALT-?
keys getting put into the JTextField. It saved me a fair
bit of time. Here is another way to do it without a
listener. The processKeyEvent() is called before
processInputMethodEvent(). You may have one small bug in
your code. Try pressing ALT-<CR> (or some other inoculous
ALT key combination) The next key stroke may be ignored
because the ignore flag is set. What I do is wipe out
the flag a the start of the processing of any key. This
would mean resetting the ignore flag in your keyPressed()
and keyTyped() methods.
Thanks again.
My patch follows:
// If the Alt+key combo is pressed then don't display
the keystroke.
// this is works around a JDK 1.2 bug.
private boolean ignoreKey;
protected void processKeyEvent(KeyEvent e) {
ignoreKey = false;
super.processKeyEvent(e);
if( e.isAltDown() &&
e.getKeyCode() != KeyEvent.VK_ALT &&
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
