I am finding problems with the optionKeyDown handler on both Windows
(where it's the ALT key) and macOS (OPTION key). This is in Livecode
9.6.7 STABLE under macOS Mojave and Windows 10
In a new stack, place the following in the card script:
on optionKeyDown pKeyName
if platform() = "MacOS" then
put numToChar(charToNum(pKeyName)-128) into tKey1 -- original
sample from Dictionary
put numToCodePoint(codepointToNum(pKeyName)-128) into tKey2 --
trying using non-deprecated functions
answer pKeyName,tKey1,tKey2
else -- windows
answer pKeyName
end if
end optionKeyDown
On macOS, the LC 9.6.7 Dictionary shows the need to strip the "high" bit
off the character to get the letter of the key pressed, for example,
OPTION-F produces ƒ
The above script on macOS produces for OPTION-F the following ƒ, D, Ë
Where as what you want for either tKey1 or tKey2 to be "F" the key
pressed with OPTION-F
I think this is a case where the Dictionary entry for optionKeyDown (for
macOS) needs to be updated with a formula that works since LC was
updated to Unicode with version 7 "High" ASCII macOS characters are now
UNicode and not the same character codes.
But Wait. Windows is even worse
This code on Windows does not produce a letter of any sort. It produces
As soon as you press the ALT key, before you can even press ALT-F, this
script displays 65513 in the answer dialog. This, I believe is the RAW
key code for the ALT key!
In other words, the optionKeyDown message is not sending the key pressed
as a letter/character as the dictionary says and the parameter passed to
the optionKeyDown message is the code for the ALT key itself (which
makes no sense).
Could enough folks on this list conform both the macOS and Windows
errors, so I can log a bug with LiveCode? I am not looking for
work-around (I can do that if I have to), just for confirmation that
these are bugs.
The macOS can be resolved by a better method for mapping macOS
"high-ASCII" characters, now mapped to Unicode in LC, back to the ASCII
key characters pressed.
The Windows may not have a work-around as, according to the dictionary,
keyDown/keyUp messages are not passed in Control or Alt keys are down,
the commandKeyDown, optionKetDown messages are sent instead, so you can
using a keyDown handler and check for the altKey() = "down" condition.
Perhaps rawKeyDown...
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
