Andreas Raab wrote:

Ctrl-M is VK_RETURN and although I don't recall the precise circumstances some parts of the image got severely confused when that key was reported normally. If you would like to experiment with it, just remove the line in sqWin32Window.c that says:

  /* Note: VK_RETURN is recorded as virtual key ONLY */
  if(keyCode == 13) return 1;

I'd be interested in finding out if this is still an issue or not (there is a good possibility that this goes back all the way to the state-based primitives which had to use a mixture of keyDown/keyChar events to produce proper results).

I applied the change and the image seems to do fine after some initial testing. It is a refactored pharo image though.

I've uploaded the VM here http://impara.de/michael/ctrl-m-VM.zip

for others to try with other images.

Michael

Andreas Raab wrote:

I'd be interested in finding out if this is still an issue or not (there is a good possibility that this goes back all the way to the state-based primitives which had to use a mixture of keyDown/keyChar events to produce proper results).

it seems both tab and cr are handled twice in paragraph editor when handled as meta keys. Not sure why yet...

Michael

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; }

Michael Rueger wrote:

Andreas Raab wrote:

...

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.

Right now we are not calling those functions/following the described procedure, right?

I'm not entirely sure what this procedure is describing ;-)

So my changes at least wouldn't make the VM less conforming than it already is ;-) Unless I'm not understanding current code and docs correctly.

Sure. I'm good with it either way - most of this stuff is weird because it attempts to translate some combos (ctrl+enter, ctrl-tab) into MDI system key combinations (I think this is why it's starts out as WM_SYSKEYDOWN in the first place so that an MDI window can capture and translate it properly). My preferred way to deal with it would be to turn all of the translations off but that's apparently not an option.

Cheers, - Andreas