<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Dave.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Next debugging step would be to confirm whether or not the "y" release</span></div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> event is being delivered to the image.</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">1) Add a "Transcript showln: anEvent" to the beginning of HandMorph >> #showEvent:.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">2) Do it: "HandMorph showEvents: true"</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">3) Open a transcript window and observe.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
                        <p style='color: #AAAAAA; margin-top: 10px;'>Am 14.01.2021 22:10:01 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style='font-family:Arial,Helvetica,sans-serif'>On Wed, Jan 13, 2021 at 08:51:03PM -0500, David T. Lewis wrote:<br>> On Tue, Jan 12, 2021 at 09:43:45PM -0800, tim Rowledge wrote:<br>> > One of the things I had to make for NuScratch was a keyboardlistener that keeps a bitmap of the keys currently pressed - quite a few Scratch things are state dependent rather than even responsive. It originally worked pretty well as far as anybody could ever see; I had no reports of problems for years.<br>> > <br>> > Whilst trying to make a 5.3 version it seems that something is making it much less reliable. It is clear from some tracking code that if one holds down a key, presses and releases another key and then finally releases the initial key, that we are losing the  final expected  key-up of the held-down key. Which in turn leaves my keyboard listener thinking the key is still pressed. This is a Bad Thing. It causes me to lose games of Asteroid Blaster. I don't like to lose at Asteroid Blaster.<br>> > <br>> > Looking at the unix VM keystroke handling code causes migraines. Has anybody got any idea what on earth is going on down there? I'll build a VM with the relevant debug code turned on soon but really... if anyone that knows this part could save some pain it would be very pleasant.<br>> ><br>> <br>> Your question reminded me of something from a previous round of<br>> debugging a similar (same?) issue circa 2011 (see Mantis 0007597).<br>> <br>> There is a standard X11 utility program called xev that displays<br>> X events as they are being generated, and another program called<br>> xwininfo that lets you identify X11 windows and their parent and<br>> children and such. I'm going to predict that the man pages are<br>> likely to drive you crazy, but if you read them patiently a few<br>> dozen times, it's all in there.<br>> <br>> The output of xev is overwhelming, but you can redirect it to a<br>> file and look through that if you're patient.<br>> <br><br>I used xev to check out the X11 events that get generated from the<br>keyboard. My test was to do this (quickly)with xev running:<br><br> - depress "x" key<br> - depreas "y" key<br> - release "y" key<br> - release "x" key<br><br>The X11 events as logged by xev were:<br><br><br>KeyPress event, serial 37, synthetic NO, window 0x4a00001,<br>    root 0x157, subw 0x0, time 47948369, (-236,-191), root:(1506,711),<br>    state 0x0, keycode 53 (keysym 0x78, x), same_screen YES,<br>    XLookupString gives 1 bytes: (78) "x"<br>    XmbLookupString gives 1 bytes: (78) "x"<br>    XFilterEvent returns: False<br><br>KeyPress event, serial 37, synthetic NO, window 0x4a00001,<br>    root 0x157, subw 0x0, time 47948766, (-236,-191), root:(1506,711),<br>    state 0x0, keycode 29 (keysym 0x79, y), same_screen YES,<br>    XLookupString gives 1 bytes: (79) "y"<br>    XmbLookupString gives 1 bytes: (79) "y"<br>    XFilterEvent returns: False<br><br>KeyRelease event, serial 37, synthetic NO, window 0x4a00001,<br>    root 0x157, subw 0x0, time 47949114, (-236,-191), root:(1506,711),<br>    state 0x0, keycode 29 (keysym 0x79, y), same_screen YES,<br>    XLookupString gives 1 bytes: (79) "y"<br>    XFilterEvent returns: False<br><br>KeyRelease event, serial 37, synthetic NO, window 0x4a00001,<br>    root 0x157, subw 0x0, time 47949541, (-236,-191), root:(1506,711),<br>    state 0x0, keycode 53 (keysym 0x78, x), same_screen YES,<br>    XLookupString gives 1 bytes: (78) "x"<br>    XFilterEvent returns: False<br><br>Conclusion: All of the necessary keyboard events are generated by the<br>X server and we can safely assume that they are being delivered to<br>the VM.<br><br>Next debugging step would be to confirm whether or not the "y" release<br>event is being delivered to the image.<br><br>Dave<br><br><br></div></blockquote>
                                        </div></body>