StrongED 4.69f7 released

When you press a key it generates a low level key number which is later on translated to an internal key number. It is this internal key number that StrongED tests using OS_Byte 121.

KeyMapper replaces a low level key number with another, this happens before the translation to an internal key number. Consequently, the internal key code for original low level key number is never generated.

Right Ctrl (low level key number 97) gets mapped to Menu button (low level key number 113). The 113 gets translated to internal key number 10 and that is what OS_Byte 121 will see. Hence a test for Ctrl (internal key number 1) will return a negative result and the menu opens as expected.

It seems that pressing right Alt on RPCEmu causes it to insert a key or mouse click to open a menu but the right Alt keypress is also passed on with internal key number 1 (ie Ctrl). Even mapping right Alt to Menu button using KeyMapper doesn’t help, it’s still reported as a Ctrl key.

But right ALT mapped using KeyMapper (on Red Squirrel) also fails to produce the menu…

If Red Squirrel also fails then that suggests it has a similar problem to RPCEmu (I don’t have Red Squirrel here so can’t test with it).

Some googling revealed that right Alt is treated as Ctrl+Alt on Windows by sending a virtual-key code for Ctrl first. RPCEmu apparently passes that on to RISC OS, so it doesn’t seem to be a StrongED problem.

Yes—I’ve just tested RPCEmu Linux version, running on the same PC (using VirtualBox to run Linux) and the problem doesn’t occur there. Looks like this is a Windows “feature”. Presumably other apps don’t show this feature as they don’t respond to a CTRL-click on the iconbar icon.

Changed StrongED to allow a Ctrl-Menu click on the iconbar icon so right Alt in RPCEmu (and presumably Red Squirrel) on Windows now produces the iconbar menu.