<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 16 déc. 2019 à 16:50, K K Subbu <<a href="mailto:kksubbu.ml@gmail.com">kksubbu.ml@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 16/12/19 8:24 PM, Marcel Taeumel wrote:<br>
> The representation of such user-input events is not necessarily specific <br>
> to Morphic, only that #keyStroke: interface is. In the long term, it <br>
> would be nice to move "UserInputEvent" etc. out of Morphic into its own <br>
> base package. This is a matter of finding a consistent, object-oriented <br>
> representation for user-input events. :-)<br>
<br>
Right. key is a physical button while keycode is what is generated by <br>
keyboard driver. keycode is a low-level numeric code. Morphic should <br>
only deal with objects like character or selector.<br></blockquote><div><br></div><div>Note that there is one more level of distinction:</div><div>- for windows, the scancode is the low-level keyboard-specific encoding (decoded by keyboard driver)</div><div>- in windows events the scancode is converted to a virtual keycode, which is device independent (VK_Enter for Enter key, etc...)</div><div>- similarly to virtual keycode, there are keysym on unix (X11)</div><div><br></div><div>
<a rel="nofollow" href="https://docs.microsoft.com/en-us/windows/win32/learnwin32/keyboard-input">https://docs.microsoft.com/en-us/windows/win32/learnwin32/keyboard-input</a> <br></div><div>
<a rel="nofollow" href="https://docs.microsoft.com/fr-fr/windows/win32/inputdev/about-keyboard-input">https://docs.microsoft.com/fr-fr/windows/win32/inputdev/about-keyboard-input</a></div><div><br></div><div>The same key on keyboard can generate several characters (a A ä ...), whether Shift, Alt Gr; or a composition key where pressed, or depending on status of caps lock, num lock, etc...</div><div>The fact that there is a different scancode generated
 or not

 when shift/ctrl is pressed is a low level implementation detail.</div><div><br></div><div>We might want to have an OS independant virtual code as charCode for key up and key down events...</div><div>That's already the case for arrows, home, end, page up, page down and a few other controls...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> it appears here, CTRL does not only modify a key (character) but <br>
> actually *modifies* a key (character). :-D Then, again, SHIFT does this, <br>
> too. Hmmm...<br>
<br>
I had to read that a couple of times to understand it ;-). CTRL modifies <br>
a keycode not a character. It was introduced to accommodate the <br>
limitations of a physical keyboard. This is why soft keyboards (like the <br>
ones on smartphones) don't need one.<br>
<br>
  <a href="https://en.wikipedia.org/wiki/Control_key" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Control_key</a><br>
  <a href="https://en.wikipedia.org/wiki/Alt_key" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Alt_key</a><br>
<br>
Regards .. Subbu<br>
<br></blockquote>This was the case on legacy keyboard for legacy apps (typewritter and console apps)<br><div>Nowadays CTRL modifies the WM_CHAR event, but the keycode remains unchanged for WM_KEYDOWN and WM_KEYUP events...</div><div>So it's not the virtual keycode which is modified! (maybe the scancode, we don't care, too low level)<br></div><div><br></div><div>The idiomatic handling CTRL may vary on different OS: windows recommend handling control+key shortcuts at keydown event, and more idiomatically thru AcceleratorTable...</div><div><a href="https://docs.microsoft.com/en-us/windows/win32/learnwin32/accelerator-tables">https://docs.microsoft.com/en-us/windows/win32/learnwin32/accelerator-tables</a></div><div>Probably not universal enough for being in the VM...</div><div><br></div><div>Do we really want to generate Start of Heading control code with the keyboard for Squeak consumption? i doubt... If we would want that, we would emulate it.</div><div>But we probably want to be able to distinguish CTRL+M from Control+Enter/Return...<br></div></div></div>