Some time ago I reported a bug about Input command not being able to detect the correct letters/keys after a dead key was pressed in Metro/Win10 apps: e.g., `a = à or 'e = é ... and others. I am reffering to AHK-L. The bug was confirmed and fixed some time ago, please see this post:

A small correction: what you're referring to is not classic AHK but AHK_L. AHK Classic (AKA Basic) is the ANSI-only version 1.0 developed by Chris.

The fix in this commit appears to have been merged here. There has been a subsequent fix to that in AHK_L, following a bug report from fincs, merged in this AHK_H commit.

However, I have noticed a small discrepancy that may or may not affect the behavior in certain context: the code is using the MOD_RSHIFT constant (I'm assuming it's VK_RSHIFT) for certain dead keys, while MSDN states that in functions where left and right modifiers cannot be differentiated, the value for left key is (or should be) used. For safety I think it should always use MOD_LSHIFT (or VK_LSHIFT where appropriate).

As of now, AHK_H has not yet been updated to AHK_L 1.1.28.02 which fixes some issue with WinActivate and restoring active window, which may or may not be related to to the erroneous behavior you reported to me earlier in MM.

You also failed to mention the layout(s) that exhibit the erroneous behavior in regard to dead keys; this may be important since I've already noticed upon testing that some layouts (such as English US International) may return 1 instead of -1 in ToUnicodeEx() for some dead keys even in XP, which screws up the entire detection system. MapVirtualKeyEx() does set the high bit for those some dead keys but its usage adds to the code complexity. Unless I did something completely wrong, that is.[EDIT] Upon further testing I noticed that MapVirtualKeyEx() does not detect as such the dead keys formed using Shift or AltGr because it doesn't take into account the keyboard state. This makes any alternate detection method unreliable if based on it.At this point I don't know other reliable method for detecting dead keys in such uncommon layouts, except maybe for directly querying the tagKbdLayer tables in the corresponding DLLs.[/EDIT]

Hopefully the developers - Lexikos, HotkeyIt, Fincs - would be so kind to share some details on this issue and maybe we could find a fix.

Last edited by Drugwash on 13 Apr 2018, 03:14, edited 1 time in total.

I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.

Haha, AHK 1.1 AKA AHK_L. I guess the latter name is better known amongst the "veterans". Still, if you go to official GitHub page and grab the sources or the docs it will be AutoHotkey_L packages. Anyway, I just pointed that out in case someone saw the "classic" reference and thought "oh no, yet another 9x […] like Drugwash - let's ignore him".

I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.

So, to sum it up: you're basically saying that, running the same simple test script, and selecting any keyboard layout that has dead keys, under current AHK_L it works correctly showing the right dead keys and combinations in both regular applications and UWP apps, while under current AHK_H it fails only in UWP apps just as it did in AHK_L before the 1.1.27.05 and 1.1.27.06 fixes were applied? Not distrusting you or anything, just trying to make it clear for myself and any developers reading this.

I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.