* prefix breaking issue Topic is solved

[evilC]

There's something odd going on with this code, and the only really pattern that I can see is that using the * prefix seems to cause bugs
Specifically, with pfx := "*", then a press of backspace triggers backspace down:: but a release of backspace triggers ^backspace up::
No such problem with pfx := ""

Code: Select all

keys := ["XButton1","XButton2", "BackSpace","h","l","d","i","o","u","pgdn","pgup"]
mods := [{mod: "", label: "base"},{mod: "^", label: "ctrl"},{mod: "+", label: "shift"}]
pfx := "*"

for i, k in keys {
  for i, modobj in mods {
    keyName := modobj.mod k
    fn := Func("KeyEvent").Bind(1, modobj.label "-" k)
    hotkey, % pfx keyName, % fn
    
    fn := Func("KeyEvent").Bind(0, modobj.label "-" k)
    hotkey, % pfx keyName " up", % fn
  }
}
return

KeyEvent(state, keyName){
    Tooltip % keyName ": state: " state
}

[swagfag]

minimal example

Code: Select all

#Requires AutoHotkey v1.1.33.02

; *c:: ; no difference whether commented or not

*c Up::
*^c:: ; Ctrl-C...
*^c Up::
*+c::
*+c Up:: ; ...registers as Shift-C Release

*v::
*v Up::
*^v::
*^v Up::

; leave these commented, 
; or uncomment either one or both, or add $hook hotkeys to restore correct behavior
; *+v::
; *+v Up::
	ToolTip % A_ThisHotkey

unrolled the first couple of iterations of ur loops. the bug occurs(and fixes itself) at multiple places while the loops run and hotkeys are being defined

[lexikos]

v1.1.33.03 should fix these issues.

Here's a more minimal example:

Code: Select all

$^a::
<^a up::MsgBox % A_ThisHotkey  ; Erroneously fires for both LCtrl-A and RCtrl-A on v1.1.33.02.

The issues were:

• Key-up hotkeys firing incorrectly because they were paired with a hotkey with overlapping but different requirements, such as <^a up firing for RCtrl+A because it was paired with ^a; or *^c up firing for Shift+C because it was paired with *+c, and both can fire for Ctrl+Shift+C.
• Unpredictable prioritization of hotkeys with the same modifiers but different L/R variants, or different modifiers when neither one is a perfect subset of the other. Priority was affected by order of definition to a degree but shifted unpredictably when hotkeys were added or removed.

The unpredictability can be seen in the fact that removing certain unrelated hotkeys from the test scripts causes the result to change. Maybe the problem goes away, or maybe it shifts to different hotkeys. There have been other issues in the past like that, with the same cause. It should not happen again because hotkeys are now sorted in a definite order down to the last hotkey.

They are sorted by:

• VK and SC.
• Whether the hotkeys have the wildcard modifier (hotkeys without it take precedence).
• The total number of neutral and left/right modifiers in use; e.g. <^>!+A has 3.
• The total number of left/right modifiers; e.g. <^>!+A has 2 and ^!+A has 0.
• The numeric value of the neutral modifier combination; i.e. !1 ^2 +4 #8.
• The numeric value of the left/right modifier combination; i.e. <^0x01 >^0x02 <!0x04 >!0x08 <+0x10 >+0x20 <#0x40 >#0x80.
• Key-down hotkey before key-up hotkey (technically it's combined with the next step, as the key-up flag is stored with the ID).
• The hotkey's ID, which is an auto-incrementing number decided when the hotkey's first variant is created.

Each item is relevant only if the previous items are "equal", so the last item comes into play only for "duplicate" hotkeys. The modifiers are used first because it's necessary to get the key-up hotkeys alongside their key-down counterparts. For instance, to prevent pairings like *+a and *!a up when you press Alt-Shift-A.

Prior to v1.1.33.03 it was sorted by:

• VK and SC.
• Whether the hotkeys have the wildcard modifier (hotkeys without it take precedence).
• The combined neutral and left/right modifiers, ignoring left/rightness:
  • If equal, whether the number of left/right modifiers is zero or non-zero.
  • If unequal, whether one hotkey's modifiers are a subset of the other hotkey's.

So if multiple hotkeys have the same VK and SC, the same selection of ^+!#, and neither or both have left/right modifiers, it was left up to qsort where they might end up.