Input command and Metro/Win10 apps = possible bug? Topic is solved

Report problems with documented functionality
robodesign
Posts: 217
Joined: 30 Sep 2017, 03:59
Facebook: marius.sucan
Contact:

Input command and Metro/Win10 apps = possible bug?

11 Jan 2018, 04:58

Hello!

I think I discovered a bug in AHK. Input command does not seem to work properly with Metro/Win10 apps.

I have the following code:

Code: [Select all] [Download] GeSHi © Codebox Plus

Main() {
Input, InputChar, L1 B V E I, {tab}
EndKey := ErrorLevel

processKey(InputChar)
if EndKey
processEndKey(endkey)
}


To be more precise... I get the key char, but if I press a dead key, the next char is not with an accent. In Notepad, Chrome or other 'common apps' I always get the proper key, even if I use dead keys.

Thank you.

Best regards, Marius.
lexikos
Posts: 5601
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Input command and Metro/Win10 apps = possible bug?

12 Jan 2018, 05:33

Which AutoHotkey version are you using?
Fixed Send/hotstrings/Input to adapt to the keyboard layout of the focused control instead of just the active window. In particular, this affects UWP apps such as Microsoft Edge.
Source: Changes & New Features - v1.1.27.01
Helgef
Posts: 2595
Joined: 17 Jul 2016, 01:02
Contact:

Re: Input command and Metro/Win10 apps = possible bug?

12 Jan 2018, 06:24

If I understand the described problem correctly, I see the same thing on win7, with this,

Code: [Select all] [Download] GeSHi © Codebox Plus

loop {
Input, InputChar, L1 B V E I, {tab}
tooltip % InputChar
}

if I press the keys to make a backtick, `, and then press the end key, {tab} (at this point the backtick symbol has not been produced yet), and then press e the tooltip says e but the text in notepad says è. Removing the V option, I get è in the tooltip, but ofc, nothing in notepad.

I tested on version 1.1.27.02 and AHK_H 1.1.26.01, I saw no difference.

Cheers.
robodesign
Posts: 217
Joined: 30 Sep 2017, 03:59
Facebook: marius.sucan
Contact:

Re: Input command and Metro/Win10 apps = possible bug?

13 Jan 2018, 04:31

Yes, that is correct... Thanks for testing it.
lexikos
Posts: 5601
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Input command and Metro/Win10 apps = possible bug?

13 Jan 2018, 19:49

So to reiterate, the problem only happens in Metro/Win10 apps, but Helgef's description of the problem occurring on systems which don't even have Metro/Win10 apps is "correct". :facepalm:

If you end input, it is no longer collecting, and the next call will not have collected the dead key.
lexikos
Posts: 5601
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Input command and Metro/Win10 apps = possible bug?

13 Jan 2018, 22:00

I have done extensive testing and have figured out both the actual bug and its fix.

Firstly, the sequence "`, Tab, e" should not produce è. If I am not running any scripts, in Notepad it produces ` e, at least on Windows 10. (Interestingly, in SciTE and Notepad++, the tab and backquote are swapped around - I presume this is a bug in the Scintilla control.)

If I am running only the test script, in Notepad I get ` è.

If I am running another script with hotstrings or I add a hotstring to the test script, in Notepad I get tab followed by è.

There are actually two bugs.

The first bug is that Tab and Escape aren't considered to complete the dead key sequence, even though they do. So after Tab is pressed, the keyboard hook considers there to still be a pending dead key. After Input processes 'e', it reinserts the pending dead key to "avoid side-effects" (this is normally necessary because converting a keycode to a character has the side-effect of removing the dead key from the system's buffer).

Code: [Select all] [Download] GeSHi © Codebox Plus

bool dead_key_sequence_complete = sPendingDeadKeyVK && aVK != VK_TAB && aVK != VK_ESCAPE;
Chris' comments explain:

Code: [Select all] [Download] GeSHi © Codebox Plus

	// I've only discovered two keys which need special handling, and they are handled below:
// VK_TAB & VK_ESCAPE
// These keys have an ascii translation but should not trigger/complete a pending dead key,
// at least not on the Spanish and Danish layouts, which are the two I've tested so far.
I tested on Spanish and Danish on Windows 10, and on Spanish on XP. Tab and Escape both served to complete the dead key sequence, contrary to the comments above.

The second bug is that if a key is used as an Input end key and the script does not also contain active hotstrings, the end key is not considered to have completed the dead key sequence. For example, with Input, InputChar, L1 B V I, a if you type `aae, you may get àaè, while Input shows 'e'.
robodesign
Posts: 217
Joined: 30 Sep 2017, 03:59
Facebook: marius.sucan
Contact:

Re: Input command and Metro/Win10 apps = possible bug?

14 Jan 2018, 05:12

Okay, thank you very much for the extensive testing. How about Metro apps? EG. Skype/Messenger. I do not get any accented letter in those.

If I use other end keys, it messes up with those as well, not just Tab.

Will fixes be implemented into a new AHK release?

Thank you.

Best regards, Marius.
Helgef
Posts: 2595
Joined: 17 Jul 2016, 01:02
Contact:

Re: Input command and Metro/Win10 apps = possible bug?

15 Jan 2018, 14:18

Firstly, the sequence "`, Tab, e" should not produce è. If I am not running any scripts, in Notepad it produces ` e, at least on Windows 10.

I see the same behaviour (Notepad it produces ` e and not è) when I suspend my scripts with hotstrings, scripts using keyboard hook hotkeys didn't matter if suspended or not. In all cases suspend caused keyboard hook to turn off. (again: win7)

cheers.
lexikos
Posts: 5601
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Input command and Metro/Win10 apps = possible bug?  Topic is solved

15 Jan 2018, 17:23

The UWP problem was a completely separate issue, due to a difference in the way UWP apps handle dead key sequences.

See v1.1.27.05.

Helgef: This is not news to me. ;)

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 3 guests