Resetting keys used in Custom Combinations Topic is solved

[Lem2001]

I like to use hotkey combinations that make the most sense to me and are the most memorable. This sometimes results in me using unusual combinations for hotkeys.

In the past when I have used standard keys as modifiers (i.e. keys separated by an ampersand) I encountered various unwanted side effects because I did not know about resetting keys at the end of the script. However, once I reset the key in question (e.g. ]::Send {]} ) then everything worked as intended.

My questions relate to resetting existing modifiers that have been used in custom combinations.

If I wanted to use a key combo such as: Shift & LWin:: without breaking any standard functionality ...

1. Should I put a tilde ~ key in front of one, both, or neither keys?

2. Should I reset them at the end of my script using something like: LShift::Send {LShift Up}

3. Should the reset of a modifier use the Up suffix or not? Should it be: LShift::Send {LShift} or LShift::Send {LShift UP} ?

4. I'm using a UK keyboard (which has single-press access to Hash # key) and I've used this Hash key as a modifier in a custom combination. I have reset it at the end of the script using: #::Send {#} which allows the key to continue to function normally when it's not being used as a modifier. This works fine, but if I then try to reset Win key using something like LWin::Send {LWin up} then Autohotkey complains of a duplicate (because it thinks my reset of the Hash key is an existing attempt to reset Win key).

If I use #L::Send {LWin up} and #R::Send {RWin up} then the script successfully compiles with no problem, but is #L and #R a valid way of specifying LWin and Rwin?

Thanks

[mikeyww]

Hello,

Have you tried the following alone yet?

Code: Select all

#Requires AutoHotkey v1.1.33
Shift & LWin::Send 1

Any problems with it?

[lexikos]

This isn't "resetting" the key, but defining an action to occur when the key is released, if it was pressed and released without pressing any other keys.

There is no need to "reset" a standard modifier, because the native function of the key is not blocked by defining a custom combination.

custom combinations have the following special behavior:

• The prefix key loses its native function, unless it is a standard modifier key or toggleable key such as CapsLock.

Source: Hotkeys - Definition & Usage | AutoHotkey

Should I put a tilde ~ key in front of one, both, or neither keys?

For non-standard prefix keys, if you want the key to have its native function immediately when you press it down, you must put a tilde before the prefix in at least one active custom combination. However, you probably don't want that for # since it would immediately type a hash before you could use it in combination with another key. For example, pressing the keys necessary to activate ~# & a::SendText "b" would produce the text #b.

For standard prefix keys, there is no need, as the key already retains its native function.

Should I reset them at the end of my script using something like: LShift::Send {LShift Up}

No. If the native function of LShift were blocked, "releasing" it like this would not be helpful. In order to preserve the behaviour of LShift in combinations not defined by the script, you need to prevent the key-down event from being blocked. That is what happens by default for standard modifier keys.

Should the reset of a modifier use the Up suffix or not?

If you are defining an action for a custom prefix key that will fire only when you release the key, I would suggest using Up for clarity, even if it isn't necessary.

Autohotkey complains of a duplicate (because it thinks my reset of the Hash key is an existing attempt to reset Win key).

This is not possible. LWin:: is not a duplicate of #::. When you use # as the last character of a hotkey or prefix (e.g. ^#, ~# & suffix or prefix & ~#), it is interpreted as a literal symbol, which is then translated to a virtual keycode according to whichever keyboard layout is active for the script when the hotkey is created.

Even Esc:: and Escape:: are not detected as duplicates, and they are actually the same key.

is #L and #R a valid way of specifying LWin and Rwin?

No. #L and #R correspond to Win+L and Win+R.

I would suggest getting into the habit of using lowercase characters for single-letter key names. Using uppercase characters may lead to confusion, since hotkeys ignore case whereas Send respects it (and applies Shift as necessary to produce that character).

Beware some differences between Shift & LWin:: and +LWin:::

• Custom combinations ignore other modifiers, so the former will activate even if you press Ctrl+Shift+LWin, whereas the latter will only activate for Shift+LWin.
• When you release a custom prefix key, the keyboard hook "forgets" that you are holding any custom prefix keys. This might be fixed at some point.

Code: Select all

; Press and hold Shift, press and release Ctrl, then press LWin.
; Press and hold Ctrl, press and release Shift, then press LAlt.
; In either case, no hotkey will activate.
; Press and hold Ctrl and Shift, then press LWin and/or LAlt.
; Both hotkeys are able to activate.
Shift & LWin::
Ctrl & LAlt::MsgBox % A_ThisHotkey

[Lem2001]

Thank you so much @Lexicos for this highly informative and detailed response. It has helped clear up several misunderstandings that I had about hotkey combinations.

• Custom combinations ignore other modifiers, so the former will activate even if you press Ctrl+Shift+LWin, whereas the latter will only activate for Shift+LWin.
• When you release a custom prefix key, the keyboard hook "forgets" that you are holding any custom prefix keys.

I have been affected by the above on quite a few occasions but, due to my poor understanding of how things work, my attempts to remedy the situation resulted in me implementing 'fixes' that just made things worse (causing me even more confusion).

This might be fixed at some point.

That would be really great if it was, because I have so much v1 code that I do not plan to switch to v2 for the foreseeable future.

Thanks again.