Community
Participate
Working Groups
Unlike AWT, KeyEvent.keyCode returns values only for special characters (ctrl, shift, ...), and 0 for all other characters. So the only way to differentiate a character is by examining KeyEvent.character. On the 102 keyboard required for Arabic, two keys give the same value for character in the English layer, these keys are the "\" key near the ENTER, and the one next to the left SHIFT key.
I think the keyboard I have in here is not same you have. Could you attach a pic of your keyboard layout ?
Created attachment 5241 [details] A picture of the Arabic 102 keyboard layout The keys creating the conflict are the rightmost key in Row C (having the "~" sign) and the leftmost in Row B (with the "|"). They both write a "\" in the English layer.
Does the problem happen only on Eclipse ?
No, the key conflict is already there. It happens in any text. The problem is, when using SWT for developing an application that relies on the keyboard layout, there is no way to determine which key of the two was used. This is because there is no identifying way other than checking for the character itself, and they both produce the same character.
Sorry but we are not able to fix this. SWT is not causing the conflict, the event is filled correctly. There is nothing we can do.
The same problem occurs in the Arabic layer in the "B" and "G" keys. The Arabic letter on the B key is a composite of 2 letters, the first of which is represented by the letter on the G key. So, in the current manner, there is no way to know which of them were pressed because they both return the same first character. Is there nothing to be done about that?
SN says, "How are we supposed to fix this? We don't have the hardware so we can't even see the problem. What values should we put into keyCode? How would we ever know that we've put in the correct values? Given that Notepad.exe has the same behavior as SWT, I think we are done here." Can you confirm that AWT "get's this right" by writing a simple AWT example and attaching it to this PR, showing the output?
This problem is not only on the 102 keyboard; regular keyboards too face the same issue with certain Arabic letter. As I explained in Comment #6, the same problem takes place with the Arabic letters on the "B" and "G" keys. >Given that Notepad.exe has the same behavior as SWT, I think we are done here. I am not talking about _typing_ the character, I am talking about _identifying_ the key that was pressed. AWT uses a unique keyCode for each key on the keyboard. SWT uses this keyCode only for special characters like Ctrl, Shift, Del,... In an Arabic keyboard layer, the keys B, Shift+B, Shift+G, Shift+T all represent composite characters that are formed of two characters, the first of which is the letter represented by the "G" key. Using KeyEvent.character will return the same character in all cases; to get around that in AWT, the keyCode is checked. So, what could be done in SWT?
Created attachment 5300 [details] test case Test program to show the differences between AWT and SWT. Try it on an Arabic layout with the specified keys.
Sorry, we misunderstood the problem because we didn't read #6 closely. The part we were missing was that one key stroke generates 2 key events.
This is blocking work on the new key binding architecture. See Bug 42035 for more information as to our requirements. We would like more information from the KeyEvent. We need one integer value to represent the modified key, and one integer value to represent the unmodified key. (note: this affects all platforms and all operating systems) (as this is blocking work for platform-ui, could you please elevate to blocker? i don't have sufficient permissions on this bug to change severity. thanks. we need a solution for M4 from SWT, and we need time to implement and test our piece after SWT provides a fix.) (also, a broader summary might be in order. <g>)
steve has applied a fix for Bug 42035, that should also fix this bug. could someone please comment?
FH?
Typing g: lam identified by: stateMask=0x0, keyCode=0x67, character=0x644 Typing h: alef identified by: stateMask=0x0, keyCode=0x68, character=0x627 Typing b: lam identified by: stateMask=0x0, keyCode=0x62, character=0x644 alef identified by: stateMask=0x0, keyCode=0x62, character=0x627 Typing SHIFT n: alef madda above identified by: stateMask=0x20000 SHIFT, keyCode=0x6e, character=0x622 Typing SHIFT h: alef hamza above identified by: stateMask=0x20000 SHIFT, keyCode=0x68, character=0x623 Typing SHIFT y: alef hamza below identified by: stateMask=0x20000 SHIFT, keyCode=0x79, character=0x625 Typing SHIFT b: lam identified by: stateMask=0x20000 SHIFT, keyCode=0x62, character=0x644 alef madda above identified by: stateMask=0x20000 SHIFT, keyCode=0x62, character=0x622 Typing SHIFT g: lam identified by: stateMask=0x20000 SHIFT, keyCode=0x67, character=0x644 alef hamza above identified by: stateMask=0x20000 SHIFT, keyCode=0x67, character=0x623 Typing SHIFT t: lam identified by : stateMask=0x20000 SHIFT, keyCode=0x74, character=0x644 alef hamza below identified by: stateMask=0x20000 SHIFT, keyCode=0x74, character=0x625 Application can identify which key was typed by looking at the keyCode. I can't see any ambiguity. Nagia/Rasha, is that what you need ?
Fixed HEAD > 20030922 Reopen this if you need.
