Page 1 of 1

Input command and Metro/Win10 apps = possible bug?

Posted: 11 Jan 2018, 04:58
by robodesign
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

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.

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

Posted: 12 Jan 2018, 05:33
by lexikos
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

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

Posted: 12 Jan 2018, 06:24
by Helgef
If I understand the described problem correctly, I see the same thing on win7, with this,

Code: Select all

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.

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

Posted: 13 Jan 2018, 04:31
by robodesign
Yes, that is correct... Thanks for testing it.

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

Posted: 13 Jan 2018, 19:49
by lexikos
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.

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

Posted: 13 Jan 2018, 22:00
by lexikos
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

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

Code: Select all

	// 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'.

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

Posted: 14 Jan 2018, 05:12
by robodesign
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.

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

Posted: 15 Jan 2018, 14:18
by Helgef
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.

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

Posted: 15 Jan 2018, 17:23
by lexikos
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. ;)