The Cocoa based VM returns  this. 

#(2 156576 0 1 8 0 0 1)
#(2 156576 97 0 8 97 0 1)
#(2 156576 0 2 8 0 0 1)


Looks like cmd-a returns on a Squeak 4.2.5 vm does return.
#(2 267194 0 1 8 0 0 1)
#(2 267194 97 0 8 97 0 1)
#(2 267295 0 2 64 0 0 1)

Shrug,  no support for that code base now... 
At this point you should migrate to the cocoa based VM. 

Also see 
https://isqueak.org/ioGetNextEvent


On Wed, Apr 22, 2015 at 11:39 AM, Kruck, Bastian <Bastian.Kruck@student.hpi.uni-potsdam.de> wrote:
 
Hello Folks,

when looking for how Cog passes keystrokes to the image, we found that the modifier bitmap of the keyUp events is left shifted by 3 bits on OS X. This seems to be a bug in Mac OS specific event handling. sqMacUIEvents.c usually unshifts the mouse buttons away before passing it to the image, but it doesn’t do that for keyup events. Something that I oversee here? This could be a fix:

Index: platforms/Mac OS/vm/sqMacUIEvents.c
===================================================================
--- platforms/Mac OS/vm/sqMacUIEvents.c (revision 3312)
+++ platforms/Mac OS/vm/sqMacUIEvents.c (working copy)
@@ -1717,7 +1717,7 @@
                        //fprintf(stdout,"\nrawkey up %i",ioMSecs());
                        key = findInKeyMap(keyCode);
                        if (key != -1) {
-                               enterKeystroke ( EventTypeKeyboard,keyCode, EventKeyUp, 0, ModifierStateCarbon(event,0));
+                               enterKeystroke ( EventTypeKeyboard,keyCode, EventKeyUp, 0, ModifierStateCarbon(event,0) >> 3);
                        }
                        removeFromKeyMap(keyCode);
           result = eventNotHandledErr;

Unfortunately, I couldn’t verify the fix as I am running Yosemite which seems to not be supported yet for building from source.

I appended the changeset which we used to find that issue. Steps to reproduce:
1) install our changeset into a Squeak4.5 image on OS X
2) run `TempSettings printEvents: true.`
3) open a Transcript
4) Press cmd+a
5) The fifth item of that Array should be 8 on the third time (but is 8<<3 instead)
        #(2 15512120 0 1 8 0 0 1)
        #(2 15512120 97 0 8 97 0 1)
        #(2 15512198 0 2 64 0 0 1)


Tobias commented that this bug could be duplicated to some other places (which we didn’t verify yet).
I am not sure, how many projects already rely on this behavior and how to go on with that.

BR,
Bastian Kruck






--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================