Hold down the modifier keys, then a number, then another number doesn't work for the second number. Probably due to interference between AutoHotkey and Synergy.

[ariofrio]

Assuming default keybindings, here is how to reproduce this:

• Hold down Ctrl and Win
• Press a number key: -> Windows switches to the nth virtual desktop
• Press another number key (without releasing Ctrl and Win!): -> the number is typed into whatever application is focused, as if Ctrl and Win were not being held down

The workaround is to release the Ctrl and Win keys, then hold them down again, before pressing another number key.

I imagine this has something to do with how AutoHotKey works with keyboard bindings. Is there a way to make this sort of scenario work as expected?

[sdias]

Hi, thanks for reporting this. This kind of thing is pretty typical with AutoHotkey, yeah. I'll see if there is something I can do to improve it.

[GioBonvi]

@ariofrio

Hi, I am currently revising all the old issues and bugs of this project: do you still experience this probem on the last version?

I was not able to repliacate this behaviour on my computer.

[ariofrio]

I just upgraded to 0.10.4. This continues to reproduce on my computer.

For reference, here is the General section in my settings.ini:

[General]
DefaultDesktop=1
TaskbarScrollSwitching=1
UseNativePrevNextDesktopSwitchingIfConflicting=0
DesktopWrapping=1

[GioBonvi]

This is definitely strange.

As sdias said before this kind of bug can happen when working with Autohotkey, so here are some questions to clarify: if you use the AHK script, which version of autohotkey do you have installed? If you use the compiled exe, which version did you compile it with? (or did you download it from the release page?)

[sdias]

So AutoHotkey has this thing where it doesn't fully track key down states of modifiers as well as you'd like, in my experience. The way I've gotten around it before was by not using the default keybinding method, and instead, when you press part of the key combination, you check the state of the modifiers to know whether or not to apply the action. The problem is that the keybindings in this project are dynamic and configurable, so I need to take that into account when I develop a solution for this. I also noticed a few glitches when abusing the keyboard shortcuts, so I'd like to tackle those at the same time.

[ariofrio]

To answer @GioBonvi questions, I am using the compiled exe downloaded from the release page, version 0.10.4.

[GioBonvi]

@ariofrio

I am trying to replicate this on one of my systems, so here are some other questions; I hope I am not bothering you too much:

• does this happen only with default keybinding (Ctrl + Win)?
• do you use the numpad or the normal digits to switch to the nth desktop?
• does the problem arise only when switching to the nth desktop or with other commands as well (e.g. Win + Ctrl + Arrows)?
• have you ever tried if the problem is still there using another keyboard on the same computer?

Thank you for your time and sorry for the inconvenience

[ariofrio]

• No, I actually use Win+X instead of Win+Ctrl+X normally, but I have tested this with the default keybinding as well.
• This occurs with both the numpad and the normal digits.
• This also occurs when using the arrow key shortcuts.
• Wow, that was a great idea. It turns out this bug only reproduces when using a remote keyboard over Synergy.

When using a regular keyboard, this works correctly. However, this bug does not reproduce for other shortcuts such as the native Win+Ctrl+Arrow, even when using Synergy. Other shortcuts, including Ctrl+A and Ctrl+Arrow in Sublime Text 3 work correctly if you keep the modifier keys held down between shortcuts, even when using Synergy.

I suspect this only occurs with any AutoHotKey script over Synergy, but have not verified it.

[GioBonvi]

Yeah, skimming google results looks like Synergy and Autohotkey often have problem when used together as they both use low level hooks to monitor key pressed and can interfere with each other.
Changing the title accordingly.