How to write a context-sensitive hotkey?

[CarlHey]

I want to write a hotkey that triggers custom function execution by clicking the middle mouse button, but wants it to only take effect in a specific window. One way is to detect the current window in the custom function and execute the corresponding code only when the target window is active. But I found that it affects the functionality of the middle mouse button in other windows, such as holding down the middle mouse button for multi-column selection in vscode.

An ideal API would be similar to ahk.add_hotkey('MButton', callback=my_callback, hotif="WinActive("ahk_exe target.exe")"), which would add #HotIf WinActive("ahk_exe target.exe") in AHK v2, or #If WinActive("ahk_exe target.exe") in AHK v1 before the rendered code.

I searched the discussion and found #212, but the workaround in it didn't solve my problem. I read the documentation and found that #IF is marked as "Not relevant for this library".

Is there any plan to implement something like this? Or is there a way to implement context-sensitive hotkeys?

[spyoungtech]

Yeah, this is something that is not yet implemented in the API. Technically, you can write this condition into your hotkey callback, but it doesn't quite provide the same behavior as HotIf:

def my_callback():
    active_window = ahk.get_active_window()
    if active_window and active_window.get_process_name() == 'target.exe':
        ...
    else:
        ahk.click(button=3)  # send click since it was captured by the hotkey

The main difference is that, depending on the hotkey definition, it will block the key still, even when the target.exe window is not active. You can possibly mitigate this by sending the captured key in an else clause. This behavior can also be changed with the ~ hotkey modifier, but still isn't quite the same as HotIf behavior, which will capture the hotkey input only when the window is active.

I can put it on the roadmap to support this. I just never thought of a great way to implement it, since it technically accepts an arbitrary expression. Though, maybe adding specific support just for use cases like WinActive is good enough for now.

[CarlHey]

Thank you. I think the key point of this feature is that it touches the boundaries of the Python abstraction layer. As you point out, since this feature receives arbitrary ahk expressions, it is difficult to simulate this behavior at the Python level. Users need to have some knowledge of ahk anyway.

Perhaps we can take the example of SQLAlchemy and simulate writing ahk expressions at the Python level to get an AhkExpr object that can eventually be "compiled" or "rendered" as an ahk expression. In this way, the hotif parameter added to the add_hotkey method can receive an AhkExpr object. This support can be done gradually, and for expressions that are not yet supported, or for those who know ahk well enough, a RawAhkExpr object can be provided to render the provided expression as-is. This can be a bit more complex but offers plenty of flexibility.

from abc import ABC

from typing_extensions import Literal, override


class AhkExpr(ABC):

    def render(self, version: Literal['v1', 'v2']) -> str:
        raise NotImplementedError


class RawAhkExpr(AhkExpr):

    def __init__(self, expr: str):
        self.expr = expr

    @override
    def render(self, version: Literal['v1', 'v2']) -> str:
        return self.expr

It would be nice to have this feature. By the way, this library is good, thanks for your work.