Hotkey control and foreign language keyboards

Propose new features and changes
User avatar
JnLlnd
Posts: 487
Joined: 29 Sep 2013, 21:29
Location: Montreal, Quebec, Canada
Contact:

Hotkey control and foreign language keyboards

08 Jan 2018, 22:13

Hi,
Changed a-z to mean vk41-vk5A when absent from the keyboard layout, except with Raw mode or when sending single unmodified characters. This allows hotkeys and sent keyboard shortcuts to work more intuitively on certain non-English keyboard layouts.
https://autohotkey.com/docs/AHKL_Change ... v1.1.27.00

@lexikos: Thanks for this change that greatly improves user experience on systems with non-US keyboards. On the same note, if the technique you used could also make the Hotkey control more compliant to current keyboard, this would be great. Consider the following example where, on some non-US keyboards (Russian in the following screen capture), the key displayed and the key returned by the control are not the same.

Code: Select all

#SingleInstance force

Gui, Add, Hotkey, h50 w200 vMyHotkey gHotkeyChanged
Gui, Show
return

HotkeyChanged:
HotkeyControl := A_GuiControl ; hotkey var name
HotkeyControl := %HotkeyControl% ; hotkey content
MsgBox, %HotkeyControl%
return
Image
:thumbup: Author of freeware Quick Access Popup, the powerful Windows folders, apps and documents launcher!
:P Now working on Quick Clipboard Editor
:ugeek: The Automator's Courses on AutoHotkey
stealzy
Posts: 91
Joined: 01 Nov 2015, 13:43

Re: Hotkey control and foreign language keyboards

10 Jan 2018, 12:14

++1
It is very frustrating that all other software use vk-codes in their Hotkey-alike controls, but AutoHotkey has its own bizarre method.
I've NEVER met program, which use letters instead vk-codes for shortcuts.

Below is the list has tested by me:
  • Opera
    Firefox (keyconfig)
    uTorrent
    MS Office 2003
    Daum Pot Player
    Media Player Classic HC
    foobar2000
    AIMP3
    KeePass
    Everything (voidtools)
    ...can't remember a hundred other programs...
Interesting fact: in the Dvorak layout letter buttons have other vk-code, corresponding to their characters. So character A has the same vk41 code.
Also, their controls display empty if shortcut not exist. AutoHotkey display "None".

Code: Select all

Hotkey, ., Label ; It means different key depending on the autohotkey gui layout at the moment.
Hotkey, ü, Label ; You can set it at german layout, but it means nothing on other layouts,
; You'll get an error if autohotkey gui has no-german layout.
Of course, we can use vk-codes! But Gui Hotkey control give us only letter. Of course, we can parse Hotkey control associated variable content and use GetKeyVK() on letter. But what vk-code does "." letter has? GetKeyVK() give us different vk-code, depending on the autohotkey gui layout at the moment. Deadlock.

Another consequence letter-hotkey method: we can't use Win button, media buttons, Space, Pause, Enter...
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Hotkey control and foreign language keyboards

12 Jan 2018, 16:42

JnLnd wrote:On the same note, if the technique you used could also make the Hotkey control more compliant to current keyboard, this would be great.
[...] the key displayed and the key returned by the control are not the same.
Perhaps you could be more specific about what you want to be implemented. I assume you want it to be less dependent on the current keyboard layout, not more. The key displayed is different because we have no control over it; the OS displays it.
stealzy wrote:It is very frustrating that all other software use vk-codes in their Hotkey-alike controls, but AutoHotkey has its own bizarre method.
I would expect that the vast majority of users find letters easier to understand and recognize than vk codes. I don't know about the other programs, but my installed version of MPC-HC does not show VK codes to the user; it shows letters. For AutoHotkey, both the GUI and the script are user interfaces.
GetKeyVK() give us different vk-code, depending on the autohotkey gui layout at the moment.
Why do you let this be a problem? If you call GetKeyVK immediately after retrieving the contents of the control, it will be using the same keyboard layout and should therefore produce the original VK.

Alternatively, you can send the HKM_GETHOTKEY (0x402) message to the control. The low byte of the return value (ErrorLevel & 0xFF) is the vk code.
Another consequence letter-hotkey method: we can't use Win button, media buttons, Space, Pause, Enter...
This is a limitation of the Windows hotkey control, not the "letter-hotkey method". I believe it can only be overcome by completely reinventing the control.

You can use Pause and media buttons; they just don't display correctly in the control.
User avatar
JnLlnd
Posts: 487
Joined: 29 Sep 2013, 21:29
Location: Montreal, Quebec, Canada
Contact:

Re: Hotkey control and foreign language keyboards

12 Jan 2018, 17:40

lexikos wrote:
JnLnd wrote:On the same note, if the technique you used could also make the Hotkey control more compliant to current keyboard, this would be great.
[...] the key displayed and the key returned by the control are not the same.
Perhaps you could be more specific about what you want to be implemented. I assume you want it to be less dependent on the current keyboard layout, not more. The key displayed is different because we have no control over it; the OS displays it.
If possible, it would be to make the control display the typed key according to the current keyboard, and display the same key as the key returned to the script. But I understand there are things Windows would not allow. Thanks, lexikos.
:thumbup: Author of freeware Quick Access Popup, the powerful Windows folders, apps and documents launcher!
:P Now working on Quick Clipboard Editor
:ugeek: The Automator's Courses on AutoHotkey
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Hotkey control and foreign language keyboards

12 Jan 2018, 17:53

So you want to change the display to match the current return value? The return value (if it is a single character) is dependent on the current keyboard layout, such that if it was registered as a hotkey, it would only work if the keyboard layout was the same. That is the polar opposite of the a-z change, which allows scripts to work independently of keyboard layout.
User avatar
JnLlnd
Posts: 487
Joined: 29 Sep 2013, 21:29
Location: Montreal, Quebec, Canada
Contact:

Re: Hotkey control and foreign language keyboards

12 Jan 2018, 18:01

lexikos wrote:That is the polar opposite of the a-z change, which allows scripts to work independently of keyboard layout.
So, this is an example of wanting something and its opposite at the same time :-)

:headwall:
:thumbup: Author of freeware Quick Access Popup, the powerful Windows folders, apps and documents launcher!
:P Now working on Quick Clipboard Editor
:ugeek: The Automator's Courses on AutoHotkey
stealzy
Posts: 91
Joined: 01 Nov 2015, 13:43

Re: Hotkey control and foreign language keyboards

13 Jan 2018, 01:23

Thanks for your attention, lexikos!
lexikos wrote:but my installed version of MPC-HC does not show VK codes to the user; it shows letters.
Yes, they all show letters relevant to buttons vk-codes in standart US layout.
I tested all software in list with 3 layouts: standart US, US Dvorak, some non-US layout.
US Dvorak has different vk-codes for buttons, so same letter has the same vk as this letter in standart US layout.
Any non-US layout buttons has same vk-codes for buttons, so same buttons has the same vk-codes as in standart US layout.

If the letters were used, Z key which corresponds to the letter W in Fr-Belgium would not be displayed in control as Z, and set as Z in US layout.
In AutoHotkey, on the contrary, Z::MsgBox triggered on W button, because it correspond Z letter in Fr-Belgium.
If SC-codes were used, US Dvorak D letter would be displayed (and set) as E.
That's how i figured out, that only VK-codes are using by all of them.
lexikos wrote:the vast majority of users find letters easier to understand and recognize
Totally agree with that :thumbup:. The trick is to let the user interact with letters, but inside to use the vk-codes.
Whenever however shortcut create, it transform user letters to vk-codes. All programs follow this standard, so who needs letter hotkeys?
If smb needs, there must be Hotkey option/modifier for them. This is the much lesser evil, than forcing coders (who will distribute their script and use Hotkey control) to translate the letters to vk-codes, aware non-working in US layout hotkeys which were installed in the local layout.

Code: Select all

/*
Symbol  |  Description
 =      |  Use letter instead vk-code of key in en-US layout,
        |  fire the hotkey only if key reproduce the same letter in current layout.
 */
w::MsgBox  ; - vk57::MsgBox
; ↑ - in v1.1.27.00 it done differently way: only if letter not exist in layout,
; but there are always some LETTERS that exist in both non-US and US layout ON DIFFERENT BUTTON.
; See example with Fr-Belgium above.
=w::MsgBox ; - w::MsgBox   - Fire only on W letter (ahk before 1.1.27.00)
;              No cheacks, no "If", easy and predictable.
I understand that this is not about gui control, but Hotkey command organization :geek:.
Anyway this possible change is supports backward compatibility :P. Hope at least in the v2 the Hotkey method to change.
Last edited by stealzy on 13 Jan 2018, 04:25, edited 2 times in total.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Hotkey control and foreign language keyboards

13 Jan 2018, 04:23

stealzy wrote:If the letters were used, Z key which corresponds to the letter W in Fr-Belgium would not be displayed in control as Z, and set as Z in US layout.
In AutoHotkey, on the contrary, Z::MsgBox triggered on W button, because it correspond Z letter in Fr-Belgium.
You are mistaken.

Z should always corresponds to vk5A, because Microsoft's documentation defines 0x5A as "Z key".

Z corresponds to vk5A on both US (Qwerty) and Fr-Belgium (Azerty) layouts, but is in two different physical locations.
  • On the US layout, sc02c (the first key after LShift) produces vk5A.
  • On the Fr-Belgium layout, sc011 (the second key after Tab) produces vk5A.
Z:: creates a hotkey which triggers when you press vk5A:
  • On the US layout, it triggers when you press Z (vk5A / sc02c).
  • On the Fr-Belgium layout, it triggers when you press Z (vk5A / sc011).
  • On the Russian layout, it triggers when you press Я (vk5A / sc02c).
When you say "triggered on W button" you probably mean "triggered by the Z key (which has a 'W' label printed on it because my physical keyboard does not match the keyboard layout)".

The thing is, you say "AutoHotkey, on the contrary", but MPC-HC behaves exactly the same way.
Any non-US layout buttons has same vk-codes for buttons, so same buttons has the same vk-codes as in standard US layout.
This is not true. Some non-US layouts assign the same vk codes to each scan code, but Fr-Belgium is not one of them.
stealzy
Posts: 91
Joined: 01 Nov 2015, 13:43

Re: Hotkey control and foreign language keyboards

13 Jan 2018, 04:39

Oh, sorry for my mistake with Fr-Belgium :facepalm:, I must have tested it on another layout, which has Z letter with another VK-code.
What do you think about code snipped above :oops:?
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Hotkey control and foreign language keyboards

13 Jan 2018, 19:54

stealzy wrote:I must have tested it on another layout, which has Z letter with another VK-code.
I doubt it. I programmatically tested all standard Windows 10 keyboard layouts, and for "z" they all produced -1 (no mapping) or 0x5A.
What do you think about code snipped above?
Is it still relevant? What is the purpose?

If you want to disregard the current keyboard layout, use the SC.

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 22 guests