How to Prevent #HotIf Hotkeys from Affecting InputHook Topic is solved

[post]

Hey all, could someone please help me with a problem.

When I use InputHook with KeyOpt "{All}", it catches all the actual keys, ignoring hotkeys defined in the script.
But when I include #HotIf, hotkeys start to affect what InputHook is getting.
In my script I need InputHook to get keys unchanged by hotkeys, and I also need #HotIf.

I tried messing around with Critical and InputLevel, but couldn't get it to work. Not even sure what I'm looking for tbh.

Here's the code. When I press "q", then "z" without #HotIf, msgbox gives "z".
With #HotIf, it gives "a". I want it to be "z" with #HotIf, not sure how to do that.

AutoHotkey 2.0-a131-2327728b

Code: Select all

#singleinstance force
get_key(){
    ih := InputHook()
    ih.KeyOpt("{ALL}", "ES")
    ih.Start()
    ih.Wait("2")
    return ih.EndKey
}
; #HotIf WinActive("File Explorer")
q::msgbox(get_key())
z::send("a")

[swagfag]

this looks like a bug tbh

Keyboard hotkeys are still in effect while an Input is in progress, but cannot be triggered by keys which the Input suppresses.

there have been some recent v1 commits addressing issues with #If, so they might fix this too once merged. i cant investigate this right now. if u want u can manually include them, recompile v2 and see if it works then

[post]

this looks like a bug tbh

Keyboard hotkeys are still in effect while an Input is in progress, but cannot be triggered by keys which the Input suppresses.

there have been some recent v1 commits addressing issues with #If, so they might fix this too once merged. i cant investigate this right now. if u want u can manually include them, recompile v2 and see if it works then

So it wasn't something simple that I was just missing? That's good to know.
I think I'll wait, adding bits to source and recompiling sounds a bit overwhelming.

[lexikos]

The documentation is a bit misleading. Hotkeys cannot be triggered by keys which the Input suppresses, but that only relates to keys which the Input can suppress. Input cannot suppress q:: in this case when q uses the k-hook method, because hook hotkeys take precedence over Input and hotstrings. q is not suppressed by the Input, and therefore can trigger the hotkey. If q uses the reg method, the Input takes precedence and may suppress the event.

If an Input suppresses modifier keys, any hook hotkeys which use them as modifiers will not fire.

Input is collected only after hook hotkeys are processed and the event is allowed; i.e. an event can be collected if it matched a hook hotkey with the ~ prefix. This applies to both InputHook and hotstrings, which are processed at the same time since they require similar processing. Some scripts rely on hook hotkeys working while an Input is in progress (such as to cancel the Input), but I do think an option to change the relative precedence of InputHook would be useful. I started to implement it at some point thinking it would be simple, but put it on the back-burner when I ran into unexpected complications.

ListHotkeys will show you which method is being used. When the hotkey is context-sensitive and there is no global variant, it must be implemented with the hook.

[post]

Ah, so #HotIf makes any keys that have no global variant use k-hook, and k-hooks take precedence over Input. Thank you for explaining it so thoroughly!
I do agree that an option to allow InputHook to get and suppress k-hooked hotkeys would be useful.

[YellowWeb]

So, the type of config the author is asking about is impossible to implement using AutoHotkey? Sad news.