Page 1 of 1
Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 09:35
by zebluk
This code should allow to release Shift by pressing F2, but it doesn't:
Code: Select all
F1::
Send {Shift down}
return
+F2::
Send {Shift up}
return
However this code works:
Code: Select all
F1::
Send {Shift down}
return
+F2::
Sleep, 100
Send {Shift up}
return
And this works as well:
Code: Select all
F1::
Send {Shift down}
return
*F2::
Send {Shift up}
return
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 09:46
by IMEime
I have no problem with it.
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 09:50
by zebluk
One of the workarounds is to add {Blind} before releasing
However in the first example, if you press F1, then pressing F2 won't release the key (don't press shift F2, only F2, the + is there to take the shift down into account)
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 09:57
by IMEime
Still, no problem at all.
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 10:09
by zebluk
Well it's even more strange then, it doesn't work here. I'm currently on #ahk on IRC and other people reported the same weird behavior. Maybe a different OS? I'm running Win 7 x64
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 10:19
by IMEime
What do you mean by doesn't work ?
What do you expect AHK to do after you commanded to press shift key firmly?
At that moment if you press F2 that results Shift+F2.
In that situation there is no way to make the same effect as press (sheer) F2.
Regards
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 10:28
by zebluk
An example scenario:
I open notepad and type some random text, then I press F1.
To test that shift is effectively down, I left click at various places of the text: instead of moving the cursor, it selects the text from where the cursor was prior to pressing F1, confirming that shift is down.
Now I press F2 (without pressing shift as it's already down virtually), and click some text, expecting the cursor to move where I click, however it keeps selecting text, because shift was not released despite the Send {Shift up}.
The code from F2:: is actually run (tested with logging), but the Send {Shift up} doesn't apply correctly (it looks like it's sent, but immediately pressed again for some reason).
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 10:42
by Helgef
You might be interested in
#HotkeyModifierTimeout.
Re: Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 26 May 2017, 10:56
by zebluk
#HotkeyModifierTimeout seems to be the reason for this behaviour, thanks. Setting #HotkeyModifierTimeout to 0 solves this problem.
So it's actually not a bug, but a consequence of the design behind HotKey management with Sends inside. Not intuitive, thanks for having shed some light on this!
Can we say "solved" ?
Re: [solved] Send {Shift up} doesn't release shift when called in the first lines of a hotkey defined with +
Posted: 27 May 2017, 04:32
by zebluk
After some re-thinking and despite Helgef great answer, I still think there's something fishy.
I understand why a mechanism like #HotkeyModifierTimeout is needed, AHK want to send clean stuff and has to release modifier keys before Sends, and press them back after it's done.
However, in the case of releasing a modifier key like {Ctrl up} {Shift up} and {Alt up}, the "auto press it down after Send" should probably NOT press back any modifier that was explicitly released in the Send keys. This is why I think it's not a problem with design after all, but a bug, and I'm removing [solved] from the title -- for now.