Hotstrings not working with accent (diacritics) in UWP Topic is solved

[orlando2bjr]

When a hotstring has a diacritic (ç, ã, ô) it doesn't trigger on UWP based apps such as Sticky Notes, Edge, OneNote, etc...
Tested on several machines (Surface Pro 3, LG Gram, built desktop system), several keyboards (ABNT2, US, mechanical, chiclet) and US and PT-BR layouts.
link to gif to steps on onedrive
Steps:
Script

Code: Select all

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn  ; Enable warnings to assist with detecting common errors.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.
::pôr::por
::de::dê

1. Run sample script
2. Open Sticky Notes and Notepad
3. Try triggering sample hotstrings on both apps.
4. Try triggering on Edge, Word 2016, Word Mobile... etc for comparison.

However, Fastkeys dev has reported that he couldn't reproduce the bug. Maybe it's related to windows locale?
Please, can anyone confirm, suggest fixes?

[lexikos]

I found this in my notes:

fix CollectInput etc to use keyboard layout of *focused control*

I can't remember why I added it to my notes, but after reading it I remembered this bug report.

UWP apps use a weird window hosting model, where the top-level window is owned by a different process to the actual app window and controls. When you change keyboard layout, it only affects the thread which owns the control, not the active window. Send, hotstrings and Input all use the keyboard layout of the active window, so they all have these issues.

It is easy to confirm even with the US and UK keyboard layouts:

• Use F1::Send @.
• Focus Edge's address bar.
• Press F1.
• Swap layouts and press F1 again.

One press produces @ and the other produces ".

I believe that changing Send and the keyboard hook to retrieve the focused control (instead of just the active window) will fix this.

[orlando2bjr]

I imagined it had something to do with UWP weird window hosting, but had no idea how. It really makes sense how you put it. Also, I'd never imagine it affects Input as well.

I'll try working around this and hope ahk 2 comes with a fix wrapped in it at least
Nice catch!
Thanks for looking into it

[lexikos]

Fixed in v1.1.27.01.