Win key mapped to 5th mouse button (with AHK)

[Polisson]

Firstly, thanks for such a great software!

Context: I've just moved from quite similar way of managing windows after few years with Autohotkey script (much fewer options but still comprehensive). This technique used simple remap like VK06::LWin which means 5th mouse button = Left Win key. I could then use the mouse button like a Win key modifier.

Use cases of my previous setup:

1. core features alike AltSnap (move, close, resize, minimize, maximize)
2. other Win key related actions (open Win menu, Win+Tab, Win+E, Win+D and lots of other Win key related actions).

Issue: Using AltSnap completely covers usecase 1. (even enhances it greatly) and completely breaks usecase 2. I know that I can set 5th mouse button to act like a hotkey but I'm loosing ability to use it like Win key (as documentation says, "... buttons will not be usable outside of AltSnap")

Possible solutions:

1. workaround using low-level Interception driver which could remap 5th button before Windows kernel perceives that, so AltSnap as well (quite difficult, needs admin rights for OS and caution)
2. workaround using Autohotkey to somehow trick AltSnap to perceive just Winkey set as hotkey (quite difficult for me because AltSnap intercepts mouse buttons, those not used also)
3. implement enhancement in AltSnap to act like remapper (like "Action without click" but for mouse which just sends logic state of chosen key e.g. LWin, LAlt etc.) - also maybe difficult, but tell my guys?

Few my artifacts: Key history from ahk, presenting simple action of moving window with 5th button remapped to Lwin in scenario: hold 5th, hold LMB, release 5th, move (invisible here), release LButton:

VK  SC  Type    Up/Dn   Elapsed Key     my comment 
-------------------------------------------------------------------------------------------------------------
06  000 h   d   1.20    XButton2        5th physical down
5B  15B i   d   0.00    LWin            remapping effect - generated by ahk
01  000     u   6.52    LButton         fake button released (probably LButton down)
5B  15B     d   2.36    LWin            ?? 
0E  000 a   d   0.02    not found       EndSendKey=0E down
0E  000 a   u   0.00    not found       EndSendKey=0E up
                        I have to release LWin manualy by presing it down>up

My AltSnap.ini file. AltSnap 1.58 Windows 10 Autohotkey 1.x

[RamonUnch]

Excuse me but I cannot reprduce the issue. To say it short: 1) I made a ahk script containing VK06::LWin and started it. 2) Started AltSnap with your config.

And I can: a. Move windows with WIN/MB5+LClick, Resize and close as well with RClick and MClick b Use Win+E of MB5+E to open the explorer.

So I am not sure what the issue is here.

[Ichisich]

@Polisson Instead of VK06::LWin Try this:

XButton2::
{
    Send "{LWin Down}"
}
XButton2 up::
{
    Send "{LWin Up}"
}

I tested it with both your use cases and it worked.

[Ichisich]

OK, I downgraded to AutoHotkey v1.1.36.02 and loaded in your ini.

As @RamonUnch said VK06::LWin works with AltSnap and Windows' native shortcuts. My guess would be, there is a third program that may interfere on your system.

[RamonUnch]

Actually I did not update AHK in years, I have version 1.1.33.02

[Polisson]

Thanks for such quick response! So let me precise one detail: to fully and reliable test this issue, Autohotkey should be started/reloaded first and AltSnap second. After reload latter gets precedence and ahk is loosing its capabilities.

@Ichisich I don't know how you could test such code, except it looked rather like this:

XButton2::
    Send {LWin Down}
return

XButton2 up::
    Send {LWin Up}
return

I've also checked this before posting issue. Obviously, this respect the rule of precedence Ahk vs AltSnap. You can say, that I need always first start AltSnap, then Ahk, but if I do so, it works for a while (random, few minutes time when AltSnap taking control and Ahk stops working in manner of MB5).

[Ichisich]

@Polisson I posted in v2 syntax, my bad.

Switching the start/loading order seems to have no implication on my system.

[Polisson]

I have no any other remapping software on this system. So maybe it's more Windows 10 specific problem. I've tested only on one machine (HP Zbook laptop), Win 10 Pro 22H2 build 19045.2486, Ahk 1.1.36.02, AltSnap 1.58. I'm considering now to test with Ahk v2, but won't upgrade my setup for now.

[RamonUnch]

Switching the start/loading order seems to have no implication on my system.

Same for me.

In theory it should not matter because the new Wnkey that is generated by AHK should be forwarded to all hooks to the system whichever their order in the chain.

I have a lats hypothesis about elevation, check if both AltSnap and AHK are started at the same privilege, ie if you run one of them elevated, they should be both, otherwise they should both run as users.

[Polisson]

Writing again long, but @RamonUnch was first, anyway:

Nope, same on Ahk2. Furthermore, I've just checked on a second workstation (Win 10 20H2). Tested privileges and admin rights before making issue (all 4 combinations: user-user, user-admin, admin-user, admin-admin). Thinking why you can't reproduce my issue, I realized one thing: I always use modifier key only on very beginning for a very short time. Precising: for long action, modifier is stroked on start and when action is just triggered key is released. AltSnap triggers action by Hotkey+click, but hotkey is needed only for triggering and not for all the time of action (you don't have to hold Hotkey to continue moving or resizing). My muscles reflex reproduce sequence:

1. Hotkey goes down
2. Action click goes down
3. Action begins
4. perception allows to Hotkey would be released, so I'm releasing it
5. Action continues (I'm moving a window)
6. Action click goes up (window is moved/resized) then Win key stays pressed after all.

If I do it with mouse in an uncomfortable (and inconsistent with keyboard) way, like:

1. hold MB5 (like modifier)
2. hold action click
3. continue action
4. release action click (end moving/resizing)
5. release hotkey (MB5) the issue isn't reproduced

Please, also during the reproducing be cautious and focused because if you make two actions in order, e.g. move and immediately resize, you won't perceive that LWin is down all the time of those two actions. Just do one of them, then drag inside any window.

[RamonUnch]

Now I can reproduce, quite annoying indeed, I will investigate...

[RamonUnch]

Have a try with this hooks.dll (for x64 version of AltSnap) hooks1.59test5_x64.zip

[Polisson]

Yes! It works like expected now. Of course, I will use it on a daily basis to test it deeper, but for now, the issue looks resolved.