It relates to this fix:
Fixed RAlt/LAlt:: sometimes failing to prevent menu activation after the user alt-tabs away from a window and reactivates it.
AltGr is
not RAlt, but rather LCtrl + RAlt. Your hotkey blocks RAlt, but not LCtrl, so AltGr+x produces LCtrl+LAlt+x, which probably doesn't have the effect you desire. The new behaviour is more correct, in my opinion.
It worked as you intended in v1.1.26.00 and earlier because, as part of a broken workaround for menu activation issues, AutoHotkey was sending
RAlt up after blocking RAlt (as a side-effect, the target window saw a lone RAlt-up, with no RAlt-down preceding it). It appears that the system injects LCtrl up before this RAlt up event. That being the case, you can get the same result as v1.1.26.00 and earlier by sending RAlt up:
Code: Select all
*RAlt::Send {Blind}{RAlt up}{LAlt Down}
*RAlt Up::Send {Blind}{LAlt Up}
The workaround is still needed on Windows 8.1 and earlier, but instead of just sending RAlt up, it is sent (to correct the system alt state) and then blocked (to prevent side-effects such as menu activation). The system still responds by "releasing" LCtrl, so this results in Windows 10 having different behaviour to previous versions. That being the case, it is probably better to apply the workaround on Windows 10 as well. If done, the script above will have the same effect as before, but your original script will work better than in v1.1.24.01. (If RAlt up is sent and
not blocked, it causes the underlines - like in
File - to disappear instead of staying visible until you actually release the key.)
If you are the administrator of your computer, you will likely get better results by remapping AltGr in the registry. See
How to globally map AltGr key to Alt key? - Stack Overflow.