FAQ-0437 KEY_TYPED events get reported for cursor key presses. In Java, they should not.


FAQ-0437 KEY_TYPED events get reported for cursor key presses. In Java, they should not.

» Symbian OS » Developer Knowledgebase » FAQ-0437

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.