It is possible that this runs afoul of WM_SYSKEYDOWN handling, see http://msdn.microsoft.com/en-us/library/ms646286(VS.85).aspx I'm not sure how to fix it but some combo of returning either true or false from the WndProc or alternatively calling (or not) DefWindowProc/TranslateAccelerato or somesuch could fix it.
Cheers, - Andreas
Michael Rueger wrote:
Michael Rueger wrote:
it seems both tab and cr are handled twice in paragraph editor when handled as meta keys. Not sure why yet...
OK, this is what I figured out and I might be completely wrong. Couldn't find any hints in documentation so it's based on trial and error.
CR and TAB act as normal keys (windows event wise) *unless* ctrl is pressed.
- removed CR and TAB from virtual key map
- add an extra keyChar event in that case (ctrl pressed together with CR
or TAB).
See code below.
Flames, pointers to docs, explanations welcome :-)
Michael
/* Map a virtual key into something the Mac understands */ int mapVirtualKey(int virtKey) { switch (virtKey) { case VK_DELETE: return 127; case VK_INSERT: return 5; case VK_PRIOR: return 11; case VK_NEXT : return 12; case VK_END : return 4; case VK_HOME : return 1; case VK_LEFT : return 28; case VK_RIGHT: return 29; case VK_UP : return 30; case VK_DOWN : return 31; // case VK_RETURN: return 13; // case VK_TAB : return 9; } return 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 || ((keyCode == 13 || keyCode == 9) && ctrl))) { /* generate extra character event */ sqKeyboardEvent *extra = (sqKeyboardEvent*)sqNextEventPut(); *extra = *evt; extra->pressCode = EventKeyChar; }