capturing right-click+left-click with autohotkey; unexpected behaviour

autohotkey, mouse, windows

Solution

Here's one that supports right click dragging!

Hotkey, LButton, off

#IfWinActive ahk_class MozillaWindowClass
RButton & LButton::
    Send X
Return

RButton::return

#IfWinNotActive ahk_class MozillaWindowClass
~$RButton::
Hotkey, LButton, on
while GetKeyState("RButton", "P") {
    continue
    }
Hotkey, LButton, off
Return

LButton::Send Y
Return

It handles `RButton` manually. When `RButton` is pressed, it enables the `LButton` hotkey and waits for `RButton` to be released before deactivating it. The `RButton` hotkey uses `~`, which passes the click through normally.

`LButton` is disabled at the start by the line at the top.

Another way would have been to send `{RButton Down}` at the start of the hotkey and `{RButton Up}` at the end.

In response to your edit, the only programs that reject Autohotkey's sent events should be those that rely on low level hooks... The real trouble with the method down at the bottom is it only sends a single click, not processing holding the button. This method, and sending down and up separately, should both do that properly.

The bug with active window described at the bottom of this answer still exists, but that's a problem with the `#IfWin[Not]Active`.

Old stuff

See the documentation on the ampersand (emphasis mine):

You can define a custom combination of two keys (except joystick buttons) by using " & " between them. In the below example, you would hold down Numpad0 then press the second key to trigger the hotkey:

Numpad0 & Numpad1::MsgBox You pressed Numpad1 while holding down Numpad0.
Numpad0 & Numpad2::Run Notepad

In the above example, Numpad0 becomes a prefix key; but this also causes Numpad0 to lose its original/native function when it is pressed by itself. To avoid this, a script may configure Numpad0 to perform a new action such as one of the following:

Numpad0::WinMaximize A   ; Maximize the active/foreground window.
Numpad0::Send {Numpad0}  ; Make the release of Numpad0 produce a Numpad0 keystroke. See comment below.

The presence of one of the above hotkeys causes the release of Numpad0 to perform the indicated action, but only if you did not press any other keys while Numpad0 was being held down.

So, following that example:

#If WinActive("ahk_class MozillaWindowClass")

RButton & LButton::
    Send X
Return

RButton::return

#If !WinActive("ahk_class MozillaWindowClass")
RButton & LButton::
    Send Y
Return

RButton::Send {RButton}

Note `RButton` requires a variant that does nothing in `WinActive`, at least with my testing (see below): `RButton::return`

Since I'm using Autohotkey standard, not Autohotkey_L, I don't have `#If` and the above was untested. The following I did test, and it works.

#IfWinActive ahk_class MozillaWindowClass
RButton & LButton::
    Send X
Return

RButton::return


#IfWinNotActive ahk_class MozillaWindowClass
RButton & LButton::
    Send Y
Return

RButton::Send {RButton}

An interesting bug I've noticed is the second (NotActive) variant applies occasionally to Firefox:

- Another window is active

- `RButton` down is sent

- Firefox is not active, so the second variant is processed

- <delay> (`RButton` is held down, though the delay could be imperceptible, in the order of milliseconds, to infinite)

- Firefox becomes active

- <delay> (still held down)

- `RButton` up is sent, which sends `RButton` as per the documentation. Because Firefox became active in the delay between the active window check and when `RButton` is sent, `RButton` is sent to Firefox.

This happens when both Firefox and another window are visible, and the other window is the active one at the time of the click.

I've tried to fix this bug by adding an extra `IfWinNotActive` check within the `RButton` hotkey, but it did not seem to work.

Problem

Original source