SUGGESTED FIX
------- canvas.c -------
*** /tmp/dzhayao Thu Sep 26 18:52:56 2002
--- canvas.c Thu Sep 26 18:52:51 2002
***************
*** 1627,1632 ****
--- 1627,1651 ----
}
DTRACE_PRINTLN("This is a keyPressed event");
+ /* XtTranslateKeycode seems to return slightly bogus values for the
+ * Escape key (keysym==1004ff69==osfXK_Cancel, xmods=2) on Solaris,
+ * so we just create the KEY_TYPED as a special case for Escape here.
+ */
+ if (keycode == java_awt_event_KeyEvent_VK_ESCAPE) {
+ awt_post_java_key_event(client_data,
+ java_awt_event_KeyEvent_KEY_TYPED,
+ NULL,
+ event->xkey.time,
+ java_awt_event_KeyEvent_VK_UNDEFINED,
+ (jchar) keysym,
+ modifiers,
+ java_awt_event_KeyEvent_KEY_LOCATION_UNKNOWN,
+ event);
+
+ DTRACE_PRINTLN("Posted a keyTyped event for VK_ESCAPE");
+ return;
+ }
+
/* Now get real keysym which looks at modifiers for keyTyped event.
* XtGetActionKeySym() returns wrong value with Kana Lock,
* so use XtTranslateKeycode().
###@###.### 2002-09-26
|
EVALUATION
The submitter is correct.
###@###.### 2002-08-20
On my Sparc, xev gives: keycode 36 (keysym 0xff1b, Escape)
We strip off the top 8 bits in adjustKeySym (mask with 0x007f) to give us
0x001b which is the unicode character for Escape.
###@###.### 2002-08-20
I noticed that in handleKeyEvent, on the key press, in the second part,
where we handle the generation of KeyTyped, XtTranslateKeycode is returning
mods=2 and keysym=1004ff69.
This keysym is osfXK_Cancel, which is #defined in HPkeysym.h, which is
#included in canvas.c.
#define osfXK_Cancel 0x1004FF69
I don't know why it wouldn't come up with XK_Escape, or even osfXK_Escape,
but it didn't.
The AWT keycode we translate it to is 3, which is VK_CANCEL, which is not in
the table as a unicode character, so no KEY_TYPED is generated.
However, VK_CANCEL really is a unicode character, 0x0018, so it should
generate a unicode character anyway. I will change the keymap table entry
for XK_Cancel.
###@###.### 2002-09-23
Why does XtTranslateKeycode confuse Escape with Cancel? Some info:
From my xmodmap:
keycode 8 = F11 F11 Cancel
note mods=2 may advance F11 to Cancel here?
keycode 36 = Escape
Note these lines in the keysym defs files:
echawkes@gradgrind:/usr/X/include/X11( 50 )% findref -i ff69
./Sunkeysym.h(98): #define SunXK_Stop 0x0000FF69 /* Same as XK_Cancel */
./keysymdef.h(126): #define XK_Cancel 0xFF69 /* Cancel, stop, abort, exit */
And further note bugid 4432364 which explains that on a Sun system, the
Stop key is F11. Or at least that's how my xmodmap has it (Stop is keycode 8).
###@###.### 2002-09-23
Maybe there is a translation installed from Escape to F11 or something like
that? I should test on linux to see what happens.
###@###.### 2002-09-23
Tested on RedHat 7.2 on a pentium. It fires the keyTyped. Updated the
Description with this info.
Also, I think this has nothing to do with translations.
###@###.### 2002-09-24
I filed 4754155 about the problem with Cancel. Since this problem only
happens on Solaris, not Linux, it's probably some kind of problem with
XtTranslateKeycode in Solaris (or it is some kind of bizarre environment
artifact, as described above).
I'm just going to special-case it in our native code by firing a keyTyped
for Escape if we fire a keyPressed. I think there is usually only one
keycode associated with the Escape key (in other words, modifiers and dead
keys don't combine with it to generate other characters), so this ought
to be fine.
###@###.### 2002-09-26
I updated /test/java/awt/event/KeyEvent/DeleteKeyTyped
to serve as a regression test for this bug.
###@###.### 2002-10-09
|
Java