Hi!
I was playing to add Function Ket support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent:
evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time; * evt->charCode = keymap[keyCode & 0xff];* * * the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value. And, it makes collisions, since for example
$p char value is 112 and F1 virtual code value is 112 too :P
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).as... http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281(v=vs.85).as... http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).as...
And so with other keys, having the same keycode in the image side with different keys...
I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:
... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1; * charCode = keyCode;* pressCode = EventKeyChar; break ... evt->timeStamp = msg->time; * evt->charCode = charCode? charCode : keymap[keyCode & 0xff];* evt->pressCode = pressCode; ...
changing only the bold lines, and It seems to work.
What do you think? Guille
On 1/26/2012 14:52, Guillermo Polito wrote:
Hi!
I was playing to add Function Ket support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent:
evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time;
- evt->charCode = keymap[keyCode & 0xff];*
the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value. And, it makes collisions, since for example
$p char value is 112 and F1 virtual code value is 112 too :P
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).as... http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281(v=vs.85).as... http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).as... http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731%28v=vs.85%29.aspx
And so with other keys, having the same keycode in the image side with different keys...
I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:
... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1;
- charCode = keyCode;* pressCode = EventKeyChar; break
... evt->timeStamp = msg->time;
- evt->charCode = charCode? charCode : keymap[keyCode & 0xff];* evt->pressCode = pressCode;
...
changing only the bold lines, and It seems to work.
What do you think?
The change makes no sense (it will break most non-ascii input like accents, umlauts, etc). You really shouldn't be using character events for handling function keys. There is no 'F11 Character' in any character encoding world-wide so trying to represent F11 as a character is completely futile. You need to use keyDown and keyUp events, since F11 & friends are KEYs not CHARACTERs.
Cheers, - Andreas
Guille
Sure!
I'm not generating Char events for F11 ;). Since F11 does not generate Char events.
The problem is that the *p* key generates the same KeyDown event than F11 for the vm. I'm only fixing that:
KeyDown and KeyUp events for p key and F1 keys have different keyCodes. I'm not sure if there will still be collisions, but right now, they are with the code as it is.
Guille
On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 1/26/2012 14:52, Guillermo Polito wrote:
Hi!
I was playing to add Function Ket support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent:
evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time;
- evt->charCode = keymap[keyCode & 0xff];*
the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value. And, it makes collisions, since for example
$p char value is 112 and F1 virtual code value is 112 too :P
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).as...
And so with other keys, having the same keycode in the image side with different keys...
I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:
... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1; * charCode = keyCode;* pressCode = EventKeyChar; break ... evt->timeStamp = msg->time;
- evt->charCode = charCode? charCode : keymap[keyCode & 0xff];* evt->pressCode = pressCode;
...
changing only the bold lines, and It seems to work.
What do you think?
The change makes no sense (it will break most non-ascii input like accents, umlauts, etc). You really shouldn't be using character events for handling function keys. There is no 'F11 Character' in any character encoding world-wide so trying to represent F11 as a character is completely futile. You need to use keyDown and keyUp events, since F11 & friends are KEYs not CHARACTERs.
Cheers,
- Andreas
Guille
The question is:
Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode? I think yes. Because the keyCode indicates the key pressed in the keyboard. Doesn't it?
Now, utf32Code should be only used on KeyChar events, and I don't care about them.
How does it work now?
(KeyDown, KeyUp) and KeyChar events send different keyCodes to the image.
Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).
Regards, Guille
On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Sure!
I'm not generating Char events for F11 ;). Since F11 does not generate Char events.
The problem is that the *p* key generates the same KeyDown event than F11 for the vm. I'm only fixing that:
KeyDown and KeyUp events for p key and F1 keys have different keyCodes. I'm not sure if there will still be collisions, but right now, they are with the code as it is.
Guille
On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab andreas.raab@gmx.dewrote:
On 1/26/2012 14:52, Guillermo Polito wrote:
Hi!
I was playing to add Function Ket support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent:
evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time;
- evt->charCode = keymap[keyCode & 0xff];*
the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value. And, it makes collisions, since for example
$p char value is 112 and F1 virtual code value is 112 too :P
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).as...
And so with other keys, having the same keycode in the image side with different keys...
I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:
... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1; * charCode = keyCode;* pressCode = EventKeyChar; break ... evt->timeStamp = msg->time;
- evt->charCode = charCode? charCode : keymap[keyCode & 0xff];* evt->pressCode = pressCode;
...
changing only the bold lines, and It seems to work.
What do you think?
The change makes no sense (it will break most non-ascii input like accents, umlauts, etc). You really shouldn't be using character events for handling function keys. There is no 'F11 Character' in any character encoding world-wide so trying to represent F11 as a character is completely futile. You need to use keyDown and keyUp events, since F11 & friends are KEYs not CHARACTERs.
Cheers,
- Andreas
Guille
More on, in the unix vm, the behavior is the following:
when pressing p:
key: 112 char: 112 type: keyDown key: 112 char: 112 type: keystroke key: 112 char: 112 type: keyUp
when pressing shift + p (P): key: 254 char: 254 type: keyDown key: 80 char: 80 type: keyDown key: 80 char: 80 type: keystroke key: 80 char: 80 type: keyUp
F1, after adding support for Function keys, key: 16 char: 16 type: keyDown key: 16 char: 16 type: keyUp
While in the windows vm:
when pressing p (the problematic one):
key: 80 char: 80 type: keyDown key: 112 char: 112 type: keystroke key: 80 char: 80 type: keyUp
when pressing shift + p (P) works the same, since P char value is the same as P virtual key value:
key: 16 char: 16 type: keyDown key: 80 char: 80 type: keyDown key: 80 char: 80 type: keystroke key: 80 char: 80 type: keyUp
F1, without touching the code, shares the same keycode than p:
key: 112 char: 112 type: keyDown key: 112 char: 112 type: keyUp
Guille
On Thu, Jan 26, 2012 at 11:43 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
The question is:
Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode? I think yes. Because the keyCode indicates the key pressed in the keyboard. Doesn't it?
Now, utf32Code should be only used on KeyChar events, and I don't care about them.
How does it work now?
(KeyDown, KeyUp) and KeyChar events send different keyCodes to the image.
Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).
Regards, Guille
On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Sure!
I'm not generating Char events for F11 ;). Since F11 does not generate Char events.
The problem is that the *p* key generates the same KeyDown event than F11 for the vm. I'm only fixing that:
KeyDown and KeyUp events for p key and F1 keys have different keyCodes. I'm not sure if there will still be collisions, but right now, they are with the code as it is.
Guille
On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab andreas.raab@gmx.dewrote:
On 1/26/2012 14:52, Guillermo Polito wrote:
Hi!
I was playing to add Function Ket support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent:
evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time;
- evt->charCode = keymap[keyCode & 0xff];*
the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value. And, it makes collisions, since for example
$p char value is 112 and F1 virtual code value is 112 too :P
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).as...
And so with other keys, having the same keycode in the image side with different keys...
I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:
... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1; * charCode = keyCode;* pressCode = EventKeyChar; break ... evt->timeStamp = msg->time;
- evt->charCode = charCode? charCode : keymap[keyCode & 0xff];* evt->pressCode = pressCode;
...
changing only the bold lines, and It seems to work.
What do you think?
The change makes no sense (it will break most non-ascii input like accents, umlauts, etc). You really shouldn't be using character events for handling function keys. There is no 'F11 Character' in any character encoding world-wide so trying to represent F11 as a character is completely futile. You need to use keyDown and keyUp events, since F11 & friends are KEYs not CHARACTERs.
Cheers,
- Andreas
Guille
turning the function into something like the one I paste below gives me the following output in windows:
for p key:
key: 112 char: 112 type: keyDown key: 112 char: 112 type: keystroke key: 112 char: 112 type: keyUp
for shift + p key (being character 16 the shift key, since it is the keycode in the platform, still different from the one in unix ¬¬):
key: 16 char: 16 type: keyDown key: 80 char: 80 type: keyDown key: 80 char: 80 type: keystroke key: 80 char: 80 type: keyUp key: 16 char: 16 type: keyUp
Regards, Guille
int recordKeyboardEvent(MSG *msg) { sqKeyboardEvent *evt; int alt, shift, ctrl; int keyCode, virtCode, pressCode;
if(!msg) return 0;
alt = GetKeyState(VK_MENU) & 0x8000; shift = (GetKeyState(VK_SHIFT) & 0x8000); ctrl = GetKeyState(VK_CONTROL) & 0x8000; /* now the key code */ virtCode = mapVirtualKey(msg->wParam); keyCode = msg->wParam; /* press code must differentiate */ switch(msg->message) { case WM_KEYDOWN: case WM_SYSKEYDOWN: if(virtCode){ keyCode = virtCode; }else if(!shift && keyCode >= 0x41 && keyCode <= 0x5A){ //If shift is not set and is a character we lowercase it keyCode = keyCode + 32; }else{ keyCode = keymap[keyCode & 0xff]; } pressCode = EventKeyDown; /* filter out repeated meta keys */ if(msg->lParam & 0x40000000) { /* Bit 30 signifies the previous key state. */ if(msg->wParam == VK_SHIFT || msg->wParam == VK_CONTROL || msg->wParam == VK_MENU) { /* okay, it's a meta-key */ return 1; } } break; case WM_KEYUP: case WM_SYSKEYUP: if(virtCode){ keyCode = virtCode; }else if(!shift && keyCode >= 0x41 && keyCode <= 0x5A){ //If shift is not set and is a character we lowercase it keyCode = keyCode + 32; }else{ keyCode = keymap[keyCode & 0xff]; } pressCode = EventKeyUp; break; case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1; pressCode = EventKeyChar; break; default: pressCode = EventKeyChar; } /* remove Ctrl+Alt codes for international keyboards */ if(ctrl && alt) { ctrl = 0; alt = 0; }
/* first the basics */ evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time; evt->charCode = keyCode; evt->pressCode = pressCode; evt->modifiers = 0; evt->modifiers |= alt ? CommandKeyBit : 0; evt->modifiers |= shift ? ShiftKeyBit : 0; evt->modifiers |= ctrl ? CtrlKeyBit : 0; evt->windowIndex = msg->hwnd == stWindow ? 0 : (int) msg->hwnd; evt->utf32Code = keyCode; /* clean up reserved */ evt->reserved1 = 0; /* note: several keys are not reported as character events; most noticably the mapped virtual keys. For those we generate extra character events here */ if(pressCode == EventKeyDown && virtCode != 0) { /* generate extra character event */ sqKeyboardEvent *extra = (sqKeyboardEvent*)sqNextEventPut(); *extra = *evt; extra->pressCode = EventKeyChar; } return 1; }
On Thu, Jan 26, 2012 at 12:07 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
More on, in the unix vm, the behavior is the following:
when pressing p:
key: 112 char: 112 type: keyDown key: 112 char: 112 type: keystroke key: 112 char: 112 type: keyUp
when pressing shift + p (P): key: 254 char: 254 type: keyDown key: 80 char: 80 type: keyDown key: 80 char: 80 type: keystroke key: 80 char: 80 type: keyUp
F1, after adding support for Function keys, key: 16 char: 16 type: keyDown key: 16 char: 16 type: keyUp
While in the windows vm:
when pressing p (the problematic one):
key: 80 char: 80 type: keyDown key: 112 char: 112 type: keystroke key: 80 char: 80 type: keyUp
when pressing shift + p (P) works the same, since P char value is the same as P virtual key value:
key: 16 char: 16 type: keyDown key: 80 char: 80 type: keyDown key: 80 char: 80 type: keystroke key: 80 char: 80 type: keyUp
F1, without touching the code, shares the same keycode than p:
key: 112 char: 112 type: keyDown key: 112 char: 112 type: keyUp
Guille
On Thu, Jan 26, 2012 at 11:43 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
The question is:
Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode? I think yes. Because the keyCode indicates the key pressed in the keyboard. Doesn't it?
Now, utf32Code should be only used on KeyChar events, and I don't care about them.
How does it work now?
(KeyDown, KeyUp) and KeyChar events send different keyCodes to the image.
Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).
Regards, Guille
On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Sure!
I'm not generating Char events for F11 ;). Since F11 does not generate Char events.
The problem is that the *p* key generates the same KeyDown event than F11 for the vm. I'm only fixing that:
KeyDown and KeyUp events for p key and F1 keys have different keyCodes. I'm not sure if there will still be collisions, but right now, they are with the code as it is.
Guille
On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab andreas.raab@gmx.dewrote:
On 1/26/2012 14:52, Guillermo Polito wrote:
Hi!
I was playing to add Function Ket support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent:
evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time;
- evt->charCode = keymap[keyCode & 0xff];*
the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value. And, it makes collisions, since for example
$p char value is 112 and F1 virtual code value is 112 too :P
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281(v=vs.85).as...
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).as...
And so with other keys, having the same keycode in the image side with different keys...
I'm trying a solution like this, providing in a Char event the keycode without mapping to the image:
... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1; * charCode = keyCode;* pressCode = EventKeyChar; break ... evt->timeStamp = msg->time;
- evt->charCode = charCode? charCode : keymap[keyCode & 0xff];* evt->pressCode = pressCode;
...
changing only the bold lines, and It seems to work.
What do you think?
The change makes no sense (it will break most non-ascii input like accents, umlauts, etc). You really shouldn't be using character events for handling function keys. There is no 'F11 Character' in any character encoding world-wide so trying to represent F11 as a character is completely futile. You need to use keyDown and keyUp events, since F11 & friends are KEYs not CHARACTERs.
Cheers,
- Andreas
Guille
Guillermo, please make the functional keys working on windows. thanks :)
On 1/26/2012 17:00, Igor Stasenko wrote:
Guillermo, please make the functional keys working on windows. thanks :)
The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).
Cheers, - Andreas
On 1/26/2012 20:45, Andreas Raab wrote:
On 1/26/2012 17:00, Igor Stasenko wrote:
Guillermo, please make the functional keys working on windows. thanks :)
The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).
Oh, and just realizing: If you want the F2 key you'll have to disable the VM's F2 handling. See http://squeakvm.org/win32/settings.html
* *EnableF2Menu*: This entry allows you to determine whether the preference menu should be shown when pressing F2. The default is 1 (true).
Cheers, - Andreas
On Thu, Jan 26, 2012 at 4:45 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 1/26/2012 17:00, Igor Stasenko wrote:
Guillermo, please make the functional keys working on windows. thanks :)
The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).
True. But it would be good if the codes reaching the image for the same function keys are the same :). But for that there should be a discussion about how to arrange the keycodes to suite the three platforms.
Cheers,
- Andreas
Guille
On 1/26/2012 22:30, Guillermo Polito wrote:
On Thu, Jan 26, 2012 at 4:45 PM, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 1/26/2012 17:00, Igor Stasenko wrote: Guillermo, please make the functional keys working on windows. thanks :) The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).True. But it would be good if the codes reaching the image for the same function keys are the same :). But for that there should be a discussion about how to arrange the keycodes to suite the three platforms.
We had this discussion already. There was general agreement that probably the best way to do this would be based on the X11/keysym.h because it seems to be the most complete source for key codes. It's just that that nobody sat down and wrote the mapping from VK_XXX to XK_YYY.
Cheers, - Andreas
Cheers, - AndreasGuille
On Thu, Jan 26, 2012 at 6:43 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 1/26/2012 22:30, Guillermo Polito wrote:
On Thu, Jan 26, 2012 at 4:45 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 1/26/2012 17:00, Igor Stasenko wrote:
Guillermo, please make the functional keys working on windows. thanks :)
The function keys work perfectly fine on Windows. You need to handle the keyDown events with the proper VK_FXX values, ranging from 0x70 (F1) through 0x87 (F24).
True. But it would be good if the codes reaching the image for the same function keys are the same :). But for that there should be a discussion about how to arrange the keycodes to suite the three platforms.
We had this discussion already. There was general agreement that probably the best way to do this would be based on the X11/keysym.h because it seems to be the most complete source for key codes. It's just that that nobody sat down and wrote the mapping from VK_XXX to XK_YYY.
Hmm, that would be good, I'll have a look tomorrow :). Thanks!
Cheers,
- Andreas
Guille
On 1/26/2012 15:43, Guillermo Polito wrote:
The question is:
Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode? I think yes. Because the keyCode indicates the key pressed in the keyboard. Doesn't it?
It does. Which is precisely the reason why it *can't* produce different values when you press the shift key with it. The KEY you are pressing does not change depending on the modifier; your OS decides that the combination of the Shift key and the P key produces an uppercase P character. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.
Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?
Now, utf32Code should be only used on KeyChar events, and I don't care about them.
How does it work now?
(KeyDown, KeyUp) and KeyChar events send different keyCodes to the image.
Which is exactly the right thing to do.
Cheers, - Andreas
Ok, right now works because in no place in the image keyDown: is handled, but that's no excuse :).
Regards, Guille
On Thu, Jan 26, 2012 at 11:17 AM, Guillermo Polito <guillermopolito@gmail.com mailto:guillermopolito@gmail.com> wrote:
Sure! I'm not generating Char events for F11 ;). Since F11 does not generate Char events. The problem is that the /p/ key generates the same KeyDown event than F11 for the vm. I'm only fixing that: KeyDown and KeyUp events for p key and F1 keys have different keyCodes. I'm not sure if there will still be collisions, but right now, they are with the code as it is. Guille On Thu, Jan 26, 2012 at 11:02 AM, Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>> wrote: On 1/26/2012 14:52, Guillermo Polito wrote:Hi! I was playing to add Function Ket support in the windows vm (yep, always the same :P), and looking at the code, I saw this in the recordKeyboardEvent: evt = (sqKeyboardEvent*) sqNextEventPut(); evt->type = EventTypeKeyboard; evt->timeStamp = msg->time; * evt->charCode = keymap[keyCode & 0xff];* * * the problem with that line is that KeyDown and KeyUp events send VirtualKeycodes as keycodes and the Char event sends a unicode char value. And, it makes collisions, since for example $p char value is 112 and F1 virtual code value is 112 too :P http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).aspx <http://msdn.microsoft.com/en-us/library/windows/desktop/ms646276%28v=vs.85%29.aspx> http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281(v=vs.85).aspx <http://msdn.microsoft.com/en-us/library/windows/desktop/ms646281%28v=vs.85%29.aspx> http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx <http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731%28v=vs.85%29.aspx> And so with other keys, having the same keycode in the image side with different keys... I'm trying a solution like this, providing in a Char event the keycode without mapping to the image: ... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13) return 1; * charCode = keyCode;* pressCode = EventKeyChar; break ... evt->timeStamp = msg->time; * evt->charCode = charCode? charCode : keymap[keyCode & 0xff];* evt->pressCode = pressCode; ... changing only the bold lines, and It seems to work. What do you think?The change makes no sense (it will break most non-ascii input like accents, umlauts, etc). You really shouldn't be using character events for handling function keys. There is no 'F11 Character' in any character encoding world-wide so trying to represent F11 as a character is completely futile. You need to use keyDown and keyUp events, since F11 & friends are KEYs not CHARACTERs. Cheers, - AndreasGuille
Hi!
On Thu, Jan 26, 2012 at 4:41 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 1/26/2012 15:43, Guillermo Polito wrote:
The question is:
Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode? I think yes. Because the keyCode indicates the key pressed in the keyboard. Doesn't it?
It does. Which is precisely the reason why it *can't* produce different values when you press the shift key with it.
The KEY you are pressing does not change depending on the modifier; your OS
decides that the combination of the Shift key and the P key produces an uppercase P character. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.
But you're talking about the keychar event and I've not modified at all it's behavior :/. And yes, I agree I should not do any conversion on KeyUp and KeyDown :).
Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?
Oh, yes I do understand. Maybe I didn't explain me fine, sorry.
The main problem is that I want keycodes to be the same through the three platforms (unix, mac and windows). And for that, I have to do a mapping somewhere (this piece of code I wrote today was to play and see how it behaves, because the codes are to be defined :) ).
So, I thought those conversions could be done through the *keymap* array. Maybe that's not the way to do the mapping, but *the* mapping should be done somewhere.
Then, after looking at how other platforms work, I reached the conclusion that if events for the same stroke have different keycodes I don't care :), since the keycode should only be important for KeyUp and KeyDown and not KeyChar (where I should only care about charCode).
Now, utf32Code should be only used on KeyChar events, and I don't care about them.
How does it work now?
(KeyDown, KeyUp) and KeyChar events send different keyCodes to the image.
Which is exactly the right thing to do.
I answered before :).
Cheers,
- Andreas
Thanks, I'm learning! Guille
On 1/26/2012 22:29, Guillermo Polito wrote:
Hi!
On Thu, Jan 26, 2012 at 4:41 PM, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 1/26/2012 15:43, Guillermo Polito wrote:The question is: Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode? I think yes. Because the keyCode indicates the key pressed in the keyboard. Doesn't it?It does. Which is precisely the reason why it *can't* produce different values when you press the shift key with it. The KEY you are pressing does not change depending on the modifier; your OS decides that the combination of the Shift key and the P key produces an uppercase P character. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.But you're talking about the keychar event and I've not modified at all it's behavior :/. And yes, I agree I should not do any conversion on KeyUp and KeyDown :).
Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?Oh, yes I do understand. Maybe I didn't explain me fine, sorry.
The main problem is that I want keycodes to be the same through the three platforms (unix, mac and windows). And for that, I have to do a mapping somewhere (this piece of code I wrote today was to play and see how it behaves, because the codes are to be defined :) ).
So, I thought those conversions could be done through the *keymap* array. Maybe that's not the way to do the mapping, but /the/ mapping should be done somewhere.
The simplest place to do the mapping is inside the image.
Cheers, - Andreas
Then, after looking at how other platforms work, I reached the conclusion that if events for the same stroke have different keycodes I don't care :), since the keycode should only be important for KeyUp and KeyDown and not KeyChar (where I should only care about charCode).
Now, utf32Code should be only used on KeyChar events, and I don't care about them. How does it work now? (KeyDown, KeyUp) and KeyChar events send different keyCodes to the image.Which is exactly the right thing to do.I answered before :).
Cheers, - AndreasThanks, I'm learning! Guille
On Thu, Jan 26, 2012 at 6:39 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 1/26/2012 22:29, Guillermo Polito wrote:
Hi!
On Thu, Jan 26, 2012 at 4:41 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 1/26/2012 15:43, Guillermo Polito wrote:
The question is:
Should KeyDown, KeyUp and KeyChar events for the same key produce the same keyCode? I think yes. Because the keyCode indicates the key pressed in the keyboard. Doesn't it?
It does. Which is precisely the reason why it *can't* produce different values when you press the shift key with it.
The KEY you are pressing does not change depending on the modifier; your
OS decides that the combination of the Shift key and the P key produces an uppercase P character. Similarly to the OS deciding that (when using dead keys for example) pressing the accent key followed by the a key produces an accented a. Would you expect the keyDown value for the accented a to change as well? This way lies complete madness.
But you're talking about the keychar event and I've not modified at all it's behavior :/. And yes, I agree I should not do any conversion on KeyUp and KeyDown :).
Maybe you don't understand what these events are used for. Consider you are writing a game and you're using shift and control key for primary and secondary weapon action. Would you expect that the person writing the game needs to handle all of the various control and shift key combos in order to find out that the user pressed the a key to move forward?
Oh, yes I do understand. Maybe I didn't explain me fine, sorry.
The main problem is that I want keycodes to be the same through the three platforms (unix, mac and windows). And for that, I have to do a mapping somewhere (this piece of code I wrote today was to play and see how it behaves, because the codes are to be defined :) ).
So, I thought those conversions could be done through the *keymap* array. Maybe that's not the way to do the mapping, but *the* mapping should be done somewhere.
The simplest place to do the mapping is inside the image.
But it's not about the simplest, it's about the better. The Vm should abstract the image from these things :/. Tomorrow Dimitry adds support for android specific keys, or I do it for Gtk and etc... and polluting the image with all that seems unnecesary.
Cheers,
- Andreas
Cheers, Guille
Hi Folks,
This is actually sort of unrelated, but I'm answering to this thread just because this is also about how VMs report keystrokes in different platforms. There are 2 things really don't like. It would be great to have these fixed on the official VMs.
On the mac, when control or command are pressed, for any keystroke the unshifted code is returned, even if shift is pressed. For instance, let's assume an US keyboard. So, [shift]+[,] generates $< and [shift]+[.] generates $>. If you run 'Sensor kbdTest' and press [shift]+[,] you correctly get $<, but if you press [control]+[shift]+[,] or [command]+[shift]+[,] you get $,. This is bad, because to detect [command]+[<] or [control]+[<] you need to write code that not only needs to know about the platform, but also about the keyboard layout, as in many layouts $< is not generated by doing [shift]+[,], but by some other combination. The same happens with most non-alphabetic keys, that usually differ in different keyboard layouts.
There is a completely separated issue, and it happens both in Windows and Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the code. So, [ctrl]+[c] generates code 3. This is consistent with the traditional meaning of the ctrl key (in dumb terminals and DOS), but it makes impossible for the image to tell (for example) between [ctrl]+[Enter] and [ctrl]+[m]. The image might want to use these keystrokes for different things, so it would be much better not to substract 64 in the VM and let the image handle it. I know it could be done by handling key down and key up events, but this would also require code that is not only platform dependent but also needs to know the mapping between key codes and characters in each platform.
In general, I think that [control], [command] and [alt/option] should not affect the character code of a keystroke, they should only set the appropriate flag so the image can decide what to do with them. This is completely different for [shift], as [shift] does indeed modify the character generated.
I haven't tested on Linux or other platforms, but things like these could also happen.
Fixing these would enable a few simplifications in the image (at least in Cuis) and also ease consistent behavior in different platforms. It would also enable the use of some keystroke combinations involving [command] and/or [control] that are problematic today.
Thanks, Juan Vuletich
For the Windowze problem, here a Guy wrote down all the problems he found:
http://www.ngedit.com/a_wm_keydown_wm_char.html
Guille
On Thu, Jan 26, 2012 at 10:42 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Folks,
This is actually sort of unrelated, but I'm answering to this thread just because this is also about how VMs report keystrokes in different platforms. There are 2 things really don't like. It would be great to have these fixed on the official VMs.
On the mac, when control or command are pressed, for any keystroke the unshifted code is returned, even if shift is pressed. For instance, let's assume an US keyboard. So, [shift]+[,] generates $< and [shift]+[.] generates $>. If you run 'Sensor kbdTest' and press [shift]+[,] you correctly get $<, but if you press [control]+[shift]+[,] or [command]+[shift]+[,] you get $,. This is bad, because to detect [command]+[<] or [control]+[<] you need to write code that not only needs to know about the platform, but also about the keyboard layout, as in many layouts $< is not generated by doing [shift]+[,], but by some other combination. The same happens with most non-alphabetic keys, that usually differ in different keyboard layouts.
There is a completely separated issue, and it happens both in Windows and Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the code. So, [ctrl]+[c] generates code 3. This is consistent with the traditional meaning of the ctrl key (in dumb terminals and DOS), but it makes impossible for the image to tell (for example) between [ctrl]+[Enter] and [ctrl]+[m]. The image might want to use these keystrokes for different things, so it would be much better not to substract 64 in the VM and let the image handle it. I know it could be done by handling key down and key up events, but this would also require code that is not only platform dependent but also needs to know the mapping between key codes and characters in each platform.
In general, I think that [control], [command] and [alt/option] should not affect the character code of a keystroke, they should only set the appropriate flag so the image can decide what to do with them. This is completely different for [shift], as [shift] does indeed modify the character generated.
I haven't tested on Linux or other platforms, but things like these could also happen.
Fixing these would enable a few simplifications in the image (at least in Cuis) and also ease consistent behavior in different platforms. It would also enable the use of some keystroke combinations involving [command] and/or [control] that are problematic today.
Thanks, Juan Vuletich
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Guillermo Polito -
Igor Stasenko -
Juan Vuletich