The value of tilde and ampersand in a MouseWheel-hotkey Topic is solved

Get help with using AutoHotkey (v2 or newer) and its commands and hotkeys
eugenesv
Posts: 171
Joined: 21 Dec 2015, 10:11

The value of tilde and ampersand in a MouseWheel-hotkey

Post by eugenesv » 30 Nov 2021, 03:17

I'm trying to create a function for horizontal scrolling in File Explorer and while researching various options that do that for one app, but not another (why isn't there one Windows API that works :(?), I've noticed that this example in the official docs uses both ~ and &

Code: Select all

~LControl & WheelUp::  ; Scroll left.
{
    Loop 2  ; <-- Increase this value to scroll faster.
        SendMessage 0x0114, 0, 0, ControlGetFocus("A")  ; 0x0114 is WM_HSCROLL and the 0 after it is SB_LINELEFT.
}
I understand some applications of the ~ prefix, e.g. I use ~Alt::Send '{Blind}{vkE8}' to mask Alt as a menu key, but at the same time, it doesn't prevent AltX keybinds because the system still sees the Alt keypress and can open a file menu on AltF

Also I use & to convert TabX into hotkeys, but then I have to manually restore single-press Tab functionality (because "The prefix key loses its native function" per docs on combo)

However, I don't really understand the value of both of them in this example.
Specifically, what is the difference between these 3 versions?
  1. ~LControl & WheelUp:: ; original
  2. LControl & WheelUp:: ; no tilde Does the horizontal scroll message have different effects (speed, distance) when it's passed with a Control?
  3. <^WheelUp:: ; no tilde, no ampersand Does making it a combo make it more reliable or something?
From some rudimentary testing there doesn't seem to be any, but given I don't understand what these do in this context, I'm also not sure what too look for in testing

Thanks!

lexikos
Posts: 9554
Joined: 30 Sep 2013, 04:07
Contact:

Re: The value of tilde and ampersand in a MouseWheel-hotkey  Topic is solved

Post by lexikos » 01 Dec 2021, 04:05

The tilde prefix is explained in detail in the documentation for the tilde prefix.

There are several differences, but not in this example.
  • Tilde prevents the key from being suppressed.
    • Tab:: suppresses Tab. Tab & x:: suppresses Tab, and also suppresses x while you are holding Tab.
    • ~Tab:: and ~Tab & x:: do not suppress Tab, while Tab & ~x:: does not suppress x.
    • Alt:: does not suppress Alt, and LCtrl & WheelUp:: does not suppress LCtrl. I don't fully understand or agree with the original developer's reasoning for this behaviour, so can't say why it is this way, except that I didn't think of changing it earlier in v2 development. In any case, adding tilde doesn't do much because the key wouldn't be suppressed anyway.
  • When applied to a custom combination prefix, tilde prevents the "fire on release" behaviour.
    • The standard modifier keys have their own special "fire on release" behaviour that is independent of custom combinations, so the tilde prefix fails to have this effect with ~LCtrl & WheelUp::. Since LCtrl:: would not suppress the key anyway, you can just use ~LCtrl:: if you want it to fire on key-down.

The custom combination syntax is primarily intended for combinations with a custom modifier key. LCtrl is a standard modifier key. There is no way to define Tab & x as a single hotkey without the ampersand.

However, there are differences, including:
  • LCtrl & WheelUp requires LCtrl to be "physically" pressed, unless you change #InputLevel, whereas <^WheelUp requires LCtrl to be "logically" pressed.
  • <^WheelUp requires RCtrl, LWin, RWin, Shift and Alt to not be pressed, whereas LCtrl & WheelUp and *<^WheelUp only require LCtrl to be pressed.
In general, using the custom combination syntax does not make a hotkey more reliable; if anything, it might do the opposite. The hotkey recognizer is optimized for standard combinations.

Post Reply

Return to “Ask for Help (v2)”