Classification: |
Java |
Category: |
Events |
Created: |
11/19/99 |
Modified: |
06/22/2001 |
Number: |
FAQ-0437 |
Platform: |
ER5 |
|
Question: I have noticed that when a cursor key is pressed, a KEY_TYPED event is also posted. Calling KeyEvent.getKeyChar() uncovers
that: reports char code 7 reports char code 8 reports char code 9 reports char code 10 Isn't this a defect? And where are the odd char codes coming from?
Answer: This is arguably a defect against the Java specs which state that keys not associated with valid Unicode characters should
not report KEY_TYPED events (if one considers a cursor key press not to be a Unicode character). The EPOC window server does
however pass cursor key presses on to the VM as key typed events. Consequently these get reported as Java KEY_TYPED events
in ER5, in v6.0 and in v6.1. In the ER5 implementation there is a further problem that the EPOC key code associated with a KEY_TYPED event is treated
as though it were a valid cp1252 character, i.e. it gets put into a one-byte buffer, with all upper bits being discarded.
For example the scan code VK_LEFT gets translated to char code EKeyLeftArrow==0x1007; when the higher bits are stripped away,
this gets reported by KeyEvent.getKeyChar() as 7. Similarly for the other cursor keys. In the case of KEY_PRESSED and KEY_RELEASED events, the EPOC key codes get converted to appropriate Java virtual key codes
and all is well when getKeyCode() is called, in whatever software version.
The best way of avoiding problems here is to detect cursor key presses only with KEY_PRESSED and KEY_RELEASED events, not
KEY_TYPED events.
|