V1 -> V2: RALT and {AppsKey} oddities Topic is solved

[thinkstorm]

Hello Team,
in my V1 script I had

Code: Select all

RALT::SendInput("{AppsKey}")

to map my right ALT key to the Windows Apps Key (my keyboard doesn't have that key). In V2, sometimes the window's App menu is opening, sometimes the correct AppsKey. In explorer, the quick access toolbar gets highlighted instead. When I map another key, say

Code: Select all

#LALT::SendInput("{AppsKey}")

The function works as intended. I also checked with

Code: Select all

RALT::
{
	MsgBox("RALT got pressed.",,"T1)
	SendInput("{AppsKey}")
}

That the code actually got executed

[boiler]

in my V1 script I had

Code: Select all

RALT::SendInput("{AppsKey}")

to map my right ALT key to the Windows Apps Key (my keyboard doesn't have that key).

Looks like you pasted v2 code there unless you created a function named SendInput() that you haven’t shown.

[thinkstorm]

yes, that's V2 code now, as I'm using V2. But it is no longer working. The V1 version (that worked) read:

Code: Select all

RWIN::
RALT::
#LALT::
	SendInput, {AppsKey}
Return

[vmech]

@thinkstorm
Can you show what contains in Key History (Ctrl-K) when you pressed {Right Alt} ?

[thinkstorm]

interesting: I have an explorer window open (C:\Program Files\AutoHotkey) and click on a file, then press the RALT key, which should not get through but instead send {AppsKey}. Here is the keylist:

Code: Select all

01  000	 	d	2.11	LButton        	
01  000	 	u	0.28	LButton        	AutoHotkey
01  000	 	d	1.03	LButton        	
01  000	 	u	0.23	LButton        	
A5  138	 	d	1.09	RAlt           	
A5  138	h	u	0.12	RAlt           	
5D  15D	i	d	0.00	AppsKey        	
5D  15D	i	u	0.00	AppsKey        	
01  000	 	d	1.78	LButton        	
01  000	 	u	0.09	LButton        	AutoHotkey

AS you can see, the window sees RAlt down and up, and then AppsKey down and up. Hm... what am I doing wrong here? I thought that

Code: Select all

RALT::

would not send RALT anymore (unless I tell it to ...)

[lexikos]

Hotkeys do not "send" keys. Send/SendInput/SendPlay/SendEvent sends keys.

RALT::SendInput "{AppsKey}" on its own will suppress the key-down and key-up events of RAlt, which will show in KeyHistory (but only for the up event, since displaying "h" takes precedence over "s"):

Code: Select all

A5  138	h	d	1.45	RAlt           	
5D  15D	i	d	0.00	AppsKey        	
5D  15D	i	u	0.00	AppsKey        	
A5  138	s	u	0.09	RAlt           	

Adding >!z:: or RAlt & z:: changes the behaviour, so RAlt is not suppressed, and the hotkey only fires on release.

Code: Select all

A5  138	 	d	1.89	RAlt           	
A5  138	h	u	0.12	RAlt           	
5D  15D	i	d	0.00	AppsKey        	
5D  15D	i	u	0.00	AppsKey        	

This is true for both v1 and v2. I did not design this behaviour, so do not know what the rationale was.

@thinkstorm
I would guess that there is more code that you are not showing, and that your v1 and v2 scripts were not equivalent.

[thinkstorm]

That totally makes sense -- funny that in V1 it worked, but I have to admit that V2 is more consistent and logical.

[lexikos]

in V1 it worked

I don't know if your phrasing is just inaccurate or if it is an indication that your understanding is incorrect.

I think more correct phrasing would likely be "the v1 code worked, but after modifying the code for v2, it did not work". The key here being after modifying the code, and v1 vs v2 having little to do with it. But this is just conjecture since it appears you haven't posted full code for either version.

[thinkstorm]

Ah, I see!

Here is the full code of version 1:

Code: Select all

RWIN::
RALT::
#LALT::
	;ShowOSD("Windows 8: Windows menu / right mouse button")
	SendInput, {AppsKey}
Return

Here is the full code of version 2:

Code: Select all

RWIN::
RALT::
#LALT::
{
	;ShowOSD("Windows 8: Windows menu / right mouse button")
	SendInput("{AppsKey}")
}

Was that what you were looking for?

[lexikos]

Both versions of the code function correctly for me, and do not produce the behaviour you described or KeyHistory like what you posted.

Both versions would produce KeyHistory like what you posted if certain hotkeys were added to the code (as I explained), hence my assumption that you had not posted the entire code. I am still doubtful that you got those results with exactly the code in your last post - and no other code in the same script - on v1.1.36.02, v2.0.2 or v2.0.3.

[lexikos]

v1.1.37.01 and v2.0.4 fix a bug which might affect hotkeys like the above, though generally only if another keyboard hook is installed after the script.

Fixed an issue with hotkeys not firing due to a race condition. If a modifier hotkey such as ~*RWin:: called Send or GetKeyState too soon, the OS could report that RWin isn't down, so the hook's modifier state would be "corrected" and hotkeys would wrongly fire or fail to fire. This was likely to occur only if another keyboard hook was installed more recently than the script's own hook, since in that case the OS would not update key state until the other hook's thread has resumed and returned.

Please see whether this helps.