a135 misses some hotkeys

[Kapitano]

a135 seems to not intercept some Win+X hotkeys.

I use these to position windows around the screen:

Code: Select all

#1 Up:: WinMove -3 , 0 , 1280 , 720 , WinGetTitle("A")
#2 Up:: WinMove -3 , 0 , 1280 , 1080 , WinGetTitle("A")
#3 Up:: WinMove -3 , 0 , 1926 , 720 , WinGetTitle("A")
#4 Up:: WinMove -3 , 0 , 1926 , 1080 , WinGetTitle("A")
#5 Up:: WinMove 1270 , 0 , 653 , 720 , WinGetTitle("A")
#6 Up:: WinMove 1270 , 0 , 653 , 1080 , WinGetTitle("A")
#7 Up:: WinMove -3 , 717 , 1280 , 366 , WinGetTitle("A")
#8 Up:: WinMove -3 , 717 , 1926 , 366 , WinGetTitle("A")
#9 Up:: WinMove 1270 , 727 , 653 , 366 , WinGetTitle("A")
#0 Up:: WinMove -3 , 0 , 960 , 1080 , WinGetTitle("A")

#2 and #6 work, but #1 and #7 trigger the default Windows 10 behavior instead. I've reverted to a133, and that works fine.

[lexikos]

I don't think it's possible for #2 and #6 to work in the version of the code that you posted. See ListHotkeys:

Code: Select all

Type	Off?	Level	Running	Name
-------------------------------------------------------------------
k-hook				#1 Up
k-hook				#3 Up
k-hook				#5 Up
k-hook				#7 Up
k-hook				#9 Up

This bug is due to how whitespace after :: is handled. The single space is trimmed out by shifting the entire string to the left by one character, including its null terminator, and the length of the buffer is not updated. That leaves the null terminator at the final character position, which fools the new line continuation code into thinking that the line ends with a continuation character (because the string of potential continuation characters is null-terminated). This causes every second hotkey to be appended to the previous line, but because there is still a null terminator between them, the appended code is effectively lost.

Some other cases:

• If there are two spaces between a:: and b(), the buffer will temporarily contain a\0:b()\0)\0 (where \0 is a null-terminator, and a was terminated for the hotkey-parsing code). In that case, line continuation will see the final ), while expression parsing will only see b()\0.
• For a::..b++ the buffer would contain a\0:b++\0+\0, which would cause line continuation to see + rather than ++, so it would erroneously cause continuation.
• Three spaces would leave the last two characters of the expression intact, but would prevent recognition of and at the end of line.

There may be other consequences of this bug unrelated to line continuation.

In short, if you just remove the space after ::, it will work.