Hello.
I tried to create some hotkey file that converts specific character into function key, such as Ctrl+Z, Ctrl+F.
It is because of my RDP program of iPad does not supports command key, instead it supports alt key combination with external Bluetooth keyboard, in some weird way.
For example, Alt+Z combination on my external keyboard with iPad, to my RDP desktop, it recognized as Ω(U+03A9).
So I tried to convert this alt key combination into function key(such as alt+z(Ω) -> ctrl+z on RDP desktop) using AutoHotkey, and it was partially successful.
However, in some cases, it works not properly.
For example, alt+c from my external keyboard on iPad sent the keystroke ç(U+00E7) to RDP desktop, and AutoHotkey can catch this by SC0E7::.
However, alt+z from my external keyboard on iPad sent the keystroke Ω(U+03A9) to RDP desktop, BUT AutoHotkey only can hook SC0A9, which is the latter byte of keystroke.
(I found this fact in key history window of AutoHotkey)
Consequently, alt+z keystroke sent Ω(U+03A9), and alt+g keystroke sent ©(U+00A9), and both keystroke can be distinguished by RDP desktop,
BUT AutoHotkey can't. Key history window of AutoHotkey reports that those two keystrokes are exactly same(VK E7, SC 0A9).
So alt+z keystroke works same as alt+g keystroke.
I really hope to make AutoHotkey distinguish those two keystroke, but I couldn't find the solution to make hotkey script for distinguish.
Please help me to find the way.
Thank you in advance.
AutoHotkey could not distinguish Ω and ©
Started by
biznok
, Jul 17 2012 11:27 AM
2 replies to this topic
#2
Guests
-
- Guests
Posted 17 July 2012 - 11:31 AM
Long story - haven't read it.
Did you save your script as unicode
Did you save your script as unicode
#3
Lexikos
-
- Administrators
-
- 8856 posts
Posted 17 July 2012 - 12:21 PM
That's rediculous. Maybe there's a way to make it behave properly?For example, Alt+Z combination on my external keyboard with iPad, to my RDP desktop, it recognized as Ω(U+03A9).
AutoHotkey_L would report them like this:Key history window of AutoHotkey reports that those two keystrokes are exactly same(VK E7, SC 0A9).
E7 00A9 U d 0.01 © E7 00A9 U u 0.00 © E7 03A9 U d 0.01 Ω E7 03A9 U u 0.00 ΩE7 is VK_PACKET, which allows a program to send a Unicode character (not really a keystroke). The "scancode" field contains a Unicode character, but it isn't actually a valid scancode. Valid scancodes are in the range 0 to 0xFF (255) plus the "extended key" flag. SC123 represents scancode 0x23 with the extended bit unset.
AutoHotkey 1.0 does not interpret these VK_PACKET events correctly; they are assumed to be ordinary keyboard events. The low byte of the character code is misinterpreted as the "scancode". AutoHotkey_L ignores all VK_PACKET events (aside from logging them in the key history).
The only solution that I am aware of is to register a keyboard hook within the script. You can search for "WH_KEYBOARD_LL" to find a general example; but be warned it is not simple.
Note: Guest's suggestion is a response to a problem commonly experienced by users of Unicode versions of AutoHotkey_L. However, I don't think it's relevant in this case, even if you were using AutoHotkey_L. Furthermore, v1.1.08 (recently released) should reduce the number of cases where saving as UTF-8 is necessary.
