Oddities with #keyDown and Sensor

> I've been playing with creating a simple 2D asteroids type game in Squeak, and when it came time to try to monitor how long the accelerator key for the rocket (up arrow in this case) had been pressed, I ran into all sorts of oddities.
>
> On an intel Mac OS X 10.6.8 box, running various Cog VMs, I found that the event passed to #keyDown: contained zero as the value, regardless of which key was pressed.
>
> On Linux, this problem seems not to exist.
>
> Again on the Mac, this test class http://paste.lisp.org/display/124816 doesn't seem to work.
>
> I was trying to grab the raw Sensor event buffer, but I can't seem to get more than a handful of events.
>
> #step is where the meat of the code is. It tries to grab events from Sensor and if they are keyboard events, put them into a buffer for examination.
>
> You evoke the test morph thusly:
>
> myMorph := MyMorph new.
> myMorph  openInWorld.
> Transcript show: myMorph aCounter.
> Transcript show: myMorph eventBuffer.
>
>
> Obviously, I'm doing something fundamentally wrong

> On 23.09.2011, at 12:15, Lawson English wrote:
> [...]
>>
>> Obviously, I'm doing something fundamentally wrong
> Yes. Do Not Use Sensor Directly From Morphic Code. Otherwise you get
> unpredictable behavior because the Morphic main loop also fetches
> events from Sensor.
>
> That said, keyboard events are indeed inconsistent across platforms,
> and you have to make do with whatever the particular platform offers.
> Be sure to look at both the 8-bit char code (evtBuf at: 3) and the 32
> bit unicode (evtBuf at: 6) - some keys may be reported only in one of
> the two places. A good strategy is to look at (evtBuf at: 6) and if it
> is 0 use (evtBuf at: 3).
>
> Note that on the Mac, keydown/up events use different codes than
> stroke events.
>
> - Bert -
>
>

> Simpler code:
>
> http://paste.lisp.org/display/124831
>
> evoke via the following in a workspace
>
> a := (MyNewMorph new) openInWorld.
> a doit.
>
> typing 'x' stops the loop
>
> a eventBuffer do: [:each| each ifNotNil: [Transcript show: each;cr]].
>
> Partial results. Note that the keyDown and KeyUp events have no valid
> data associated with them. At this point, I would say its definitely a
> VM issue (either that, or Mac OS X doesn't include the data, period,
> which seems odd).
>
> #(1 11688796 358 202 0 0 0 1)
> #(2 11688821 2 2 0 0 0 1)
> #(2 11689589 2 1 0 0 0 1)
> #(2 11689589 100 0 0 100 0 1)
> #(2 11690028 2 2 0 0 0 1)
> #(2 11690381 2 1 0 0 0 1)
> #(2 11690381 100 0 0 100 0 1)
> #(2 11690604 2 2 0 0 0 1)
> #(2 11690907 2 1 0 0 0 1)
> #(2 11690907 100 0 0 100 0 1)
> #(2 11691092 2 2 0 0 0 1)
> #(2 11691284 2 1 0 0 0 1)
> #(2 11691284 100 0 0 100 0 1)
>
>
>
>
> Lawson
>
>

> So, based on guesswork and what little I understood of various comments that John Mcintosh and others have said in previous threads about the keydown/keyup issue I've been having with Mac OS X 10.6.8, I managed to patch a Cog VM to workaround the issue.
>
> I just modified the calls to enterKeystroke()  for keydown and keyup to use the same parameters as for a keystroke event, when called from within the function recordKeyboardEventCarbon().
>
> Now, keydown events report the same keyvalue as the keystroke event. Keyup events report what appears to be the raw keyscan code. Why it works as it does, precisely, I'm not sure, but it is enough  for me to track when a spaceship is accelerated by the arrow keys and gives sufficient info in the keyup event for me to figure out how long a given key has been pressed when multiple keys are held down (I think). [My first VM patch -wheeee!]
>
> The test code below now generates:  :
>
> #(2 100501 2 2 0 0 0 1)
> #(2 102403 28 1 0 0 0 1)  "keydown"
> #(2 102403 28 0 0 28 0 1) "keystroke"
> #(2 102500 123 2 0 0 0 1) "keyup"
> #(2 103139 30 1 0 0 0 1)
> #(2 103139 30 0 0 30 0 1)
> #(2 103220 126 2 0 0 0 1)
> #(2 103779 29 1 0 0 0 1)
> #(2 103779 29 0 0 29 0 1)
> #(2 103868 124 2 0 0 0 1)
> #(2 104683 31 1 0 0 0 1)
> #(2 104683 31 0 0 31 0 1)
> #(2 104756 125 2 0 0 0 1)
> #(2 105771 32 1 0 0 0 1)
> #(2 105771 32 0 0 32 0 1)
> #(2 105884 49 2 0 0 0 1)
> #(2 111772 120 1 0 0 0 1)
>
> On 9/23/11 8:05 PM, Lawson English wrote:
>> Simpler code:
>>
>> http://paste.lisp.org/display/124831
>>
>> evoke via the following in a workspace
>>
>> a := (MyNewMorph new) openInWorld.
>> a doit.
>>
>> typing 'x' stops the loop
>>
>> a eventBuffer do: [:each| each ifNotNil: [Transcript show: each;cr]].
>>
>> Partial results. Note that the keyDown and KeyUp events have no valid data associated with them. At this point, I would say its definitely a VM issue (either that, or Mac OS X doesn't include the data, period, which seems odd).
>>
>> #(1 11688796 358 202 0 0 0 1)
>> #(2 11688821 2 2 0 0 0 1)
>> #(2 11689589 2 1 0 0 0 1)
>> #(2 11689589 100 0 0 100 0 1)
>> #(2 11690028 2 2 0 0 0 1)
>> #(2 11690381 2 1 0 0 0 1)
>> #(2 11690381 100 0 0 100 0 1)
>> #(2 11690604 2 2 0 0 0 1)
>> #(2 11690907 2 1 0 0 0 1)
>> #(2 11690907 100 0 0 100 0 1)
>> #(2 11691092 2 2 0 0 0 1)
>> #(2 11691284 2 1 0 0 0 1)
>> #(2 11691284 100 0 0 100 0 1)
>>
>>
>>
>>
>> Lawson
>>
>>
>

> So, based on guesswork and what little I understood of various comments
> that John Mcintosh and others have said in previous threads about the
> keydown/keyup issue I've been having with Mac OS X 10.6.8, I managed to
> patch a Cog VM to workaround the issue.
>
> I just modified the calls to enterKeystroke()  for keydown and keyup to
> use the same parameters as for a keystroke event, when called from within
> the function recordKeyboardEventCarbon().
>
> Now, keydown events report the same keyvalue as the keystroke event. Keyup
> events report what appears to be the raw keyscan code. Why it works as it
> does, precisely, I'm not sure, but it is enough  for me to track when a
> spaceship is accelerated by the arrow keys and gives sufficient info in
> the keyup event for me to figure out how long a given key has been pressed
> when multiple keys are held down (I think). [My first VM patch -wheeee!]
>
> The test code below now generates:  :
>
> #(2 100501 2 2 0 0 0 1)
> #(2 102403 28 1 0 0 0 1)  "keydown"
> #(2 102403 28 0 0 28 0 1) "keystroke"
> #(2 102500 123 2 0 0 0 1) "keyup"
> #(2 103139 30 1 0 0 0 1)
> #(2 103139 30 0 0 30 0 1)
> #(2 103220 126 2 0 0 0 1)
> #(2 103779 29 1 0 0 0 1)
> #(2 103779 29 0 0 29 0 1)
> #(2 103868 124 2 0 0 0 1)
> #(2 104683 31 1 0 0 0 1)
> #(2 104683 31 0 0 31 0 1)
> #(2 104756 125 2 0 0 0 1)
> #(2 105771 32 1 0 0 0 1)
> #(2 105771 32 0 0 32 0 1)
> #(2 105884 49 2 0 0 0 1)
> #(2 111772 120 1 0 0 0 1)
>
> On 9/23/11 8:05 PM, Lawson English wrote:
>> Simpler code:
>>
>> http://paste.lisp.org/display/124831
>>
>> evoke via the following in a workspace
>>
>> a := (MyNewMorph new) openInWorld.
>> a doit.
>>
>> typing 'x' stops the loop
>>
>> a eventBuffer do: [:each| each ifNotNil: [Transcript show: each;cr]].
>>
>> Partial results. Note that the keyDown and KeyUp events have no valid
>> data associated with them. At this point, I would say its definitely a VM
>> issue (either that, or Mac OS X doesn't include the data, period, which
>> seems odd).
>>
>> #(1 11688796 358 202 0 0 0 1)
>> #(2 11688821 2 2 0 0 0 1)
>> #(2 11689589 2 1 0 0 0 1)
>> #(2 11689589 100 0 0 100 0 1)
>> #(2 11690028 2 2 0 0 0 1)
>> #(2 11690381 2 1 0 0 0 1)
>> #(2 11690381 100 0 0 100 0 1)
>> #(2 11690604 2 2 0 0 0 1)
>> #(2 11690907 2 1 0 0 0 1)
>> #(2 11690907 100 0 0 100 0 1)
>> #(2 11691092 2 2 0 0 0 1)
>> #(2 11691284 2 1 0 0 0 1)
>> #(2 11691284 100 0 0 100 0 1)
>>
>>
>>
>>
>> Lawson
>>
>>
>

>
> Nice that it works for your purpose. It's wrong, however.
>
> The keycodes in down and up events really should match. And they should refer to raw keys. E.g., you should get the same keycode for X and Shift-X (though for Shift-A you would get additional Shift-Down and Shift-Up events).
>
> I am sure this was working at some point. So we just need to find out where along the way it got broken.
>
> I just took a look using a 4.2 Mac VM. And lo and behold, the VM *does* work, it produces the expected key down/up codes. Which btw are Apple's "Virtual Keycodes", see e.g. http://boredzo.org/blog/archives/2007-05-22/virtual-key-codes
>
> However, Morphic event handling was broken when the keyboard interpreter was added. That must be used only for stroke events, not for up/down events. I just fixed that in trunk. And it works! Not bad for a two-line fix.
>
> And trying that Morphic fix on a Cog VM works fine. So, no VM change needed. All is good. (Well, could be better, like reporting shift-up/down too, but at least most keys are working)
>
> Have fun!
>
> - Bert -
>