Thanks Mariano, I added this to http://bugs.squeak.org/view.php?id=7611 so the issue will be tracked.
The standard VM and the Cog VM share identical support code for this function, so I am assuming that the issue affects all Windows VMs (please correct me if this is wrong). Andreas, Eliot - this would be a one-line fix in the support code if you approve, and should be applied to both the trunk and the cog branches. Thanks, Dave. On Sun, Mar 06, 2011 at 04:12:24PM +0100, Mariano Martinez Peck wrote: > > Hi, I fordward this thread to the VM mailing list since it looks more > appropiated. > David, here "tn" is proposing a fix. I am not qualified to take a look. > Hope it helps > > Mariano > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Sat, Mar 5, 2011 at 9:23 PM > Subject: Re: [Pharo-project] Issue 1064 in pharo: There are still problem > with keyboard shortcuts in Windows > To: [email protected] > > > > Comment #14 on issue 1064 by [email protected]: There are still problem > with keyboard shortcuts in Windows > > http://code.google.com/p/pharo/issues/detail?id=1064 > > Hi, I'm tn. > > 'ctrl + m' problem is Cog VM bug. > > Normally, when character key is pushed, keyboard events occur as follows on > Squeak. > > 1. key press (down) > 2. character (character code notification) > 3. key release (up) > > They are produced by a primitive method in IutEventFetcher >> > primGetNextEvent. > But when ctrl + m is pushed, a character event doesn't occur. > Because 'ctrl + m' value is 13. The value is same as ENTER key. > Cog VM ignores WM_CHAR message(character event) when ENTER key is pushed. > > The one of solution for this problem is to add CTRL key state to the > if-condition. > > -- sqWin32Window.c -- > > int recordKeyboardEvent(MSG *msg) { > ... > > switch(msg->message) { > ... > > case WM_CHAR: > case WM_SYSCHAR: > /* Note: VK_RETURN is recorded as virtual key ONLY */ > if(keyCode == 13 && !ctrl) return 1; // add "&& !ctrl" > pressCode = EventKeyChar; > break; > ... > } > ... > > Note: ENTER keyCode is 13. But when ctrl + ENTER is pushed, the keyCode is > 10. > So if the condition is revised, ctrl + m problem is corrected. > but other behavior is not changed. > > > If you want to prevent to generate character event for CTRL + ENTER, > you can add following code. By this way, we can produce > not only ctrl+m (0x0D)'s character event but also ctrl+j (0x0A)'s one. > > -- sqWin32Window.c -- > > // add this function > static int isNotKeyDownCtrlReturn(MSG* msgp){ > if(msgp->message == WM_KEYDOWN && msgp->wParam == VK_RETURN){ > if(GetKeyState(VK_CONTROL) & 0x8000) { > return FALSE; > } > } > return TRUE; > } > > ... > > int ioProcessEvents(void) > { static MSG msg; > ... > if(isNotKeyDownCtrlReturn(&msg)){ // add > TranslateMessage(&msg); > } // add > DispatchMessage(&msg); > ... > } > > ... > > int recordKeyboardEvent(MSG *msg) { > ... > > if(pressCode == EventKeyDown && virtCode != 0 && > isNotKeyDownCtrlReturn(lastMessage) ) { > // add " && > isNotKeyDownCtrlReturn(lastMessage) " > /* generate extra character event */ > ... > } > return 1; > } > > An attached file is source, which has been corrected by above way. > > > Note: Below is a comment in the source code. > > /* note: several keys are not reported as character events; > most noticably the mapped virtual keys. For those we > generate extra character events here */ > > Those keys(e.g. arrow) should not be ascii code. > ENTER key is not. but an extra character events is created for ENTER. > I don't think this behavior is correct. > As for ENTER key, an extra character event must not be generated, > and WM_CHAR message should be processed. > Please see MSDN about TranslateMessage. > > > see also Comment 11. > > Thanks, > > Attachments: > sqWin32Window.c 99 KB
