[Fixed] Input box triggered by Rcontrol or Lcontrol

Report problems with documented functionality
User avatar
Joe Glines
Posts: 540
Joined: 30 Sep 2013, 20:49
Facebook: https://www.facebook.com/theAutomatorGuru/
Google: https://plus.google.com/105328929654286634910
GitHub: joetazz
Location: Dallas
Contact:

[Fixed] Input box triggered by Rcontrol or Lcontrol

16 Apr 2015, 08:05

I finally put my finger on a problem I've run into over the past couple years. :D

When I use either the right or left control key for my hotkey to trigger input for a message box (or in a gui), I am not able to type in the input box / (edit field on gui). I can paste text but cannot type. I thought this was a UAC issue or something like that but I'm pretty sure I've isolated this.

RControl::
LControl::
InputBox, var, store a var
return
User avatar
boiler
Posts: 2370
Joined: 21 Dec 2014, 02:44

Re: Input box triggered by Rcontrol or Lcontrol

16 Apr 2015, 10:08

Interesting. Here's a fix for it in the meantime.

Code: [Select all] [Download] (Script.ahk)GeSHi © Codebox Plus

LControl::
RControl::
Send {LControl up}{RControl up}
InputBox, var, store a var
return

A similar thing happens with LShift and RShift. It is as if the shift key is held down when you type in the input box, which is what is happening with the control key.
User avatar
Joe Glines
Posts: 540
Joined: 30 Sep 2013, 20:49
Facebook: https://www.facebook.com/theAutomatorGuru/
Google: https://plus.google.com/105328929654286634910
GitHub: joetazz
Location: Dallas
Contact:

Re: Input box triggered by Rcontrol or Lcontrol

14 May 2015, 18:14

Just curious if there are any plans to fix this or if the above "solution" is good enough. I don't like it as I use the Rcontrol in nearly all my "testing" scripts and don't want to have to remember to do the extra work...
User avatar
Nextron
Posts: 1141
Joined: 01 Oct 2013, 08:23
Location: Netherlands OS: Win7 x64 AHK: Unicode x32

Re: Input box triggered by Rcontrol or Lcontrol

14 May 2015, 18:41

It's the same with every key. I'm guessing it has to do with the fact that once a inputbox/messagebox is opened, that thread is interrupted or with a context menu all of AHK is. The latter was a Windows issue, I'm not sure if that applies to the former or that's by design.

So when you press the key and the inputbox is opened immediately after, the release isn't registered. A KeyWait % A_ThisHotkey before the two should prevent the problem. Or you could change the hotkey to the up event: LControl up::InputBox, var, store a var.
The more I know:
The more I know,
I know nothing.
Guest

Re: Input box triggered by Rcontrol or Lcontrol

15 May 2015, 05:30

Adding ~ might solve it for you?

Code: [Select all] [Download] GeSHi © Codebox Plus

~RControl::
~LControl::
InputBox, var, store a var
return
User avatar
Joe Glines
Posts: 540
Joined: 30 Sep 2013, 20:49
Facebook: https://www.facebook.com/theAutomatorGuru/
Google: https://plus.google.com/105328929654286634910
GitHub: joetazz
Location: Dallas
Contact:

Re: Input box triggered by Rcontrol or Lcontrol

15 May 2015, 08:12

In my quick tests adding the tilde as suggested above solved the problem. :) I use these a lot and will report back if there are times where it doesn't work. Thank you!
lexikos
Posts: 5938
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Input box triggered by Rcontrol or Lcontrol

24 May 2015, 01:44

This also happens with MsgBox and the system message box:

Code: [Select all] [Download] GeSHi © Codebox Plus

LControl::
DllCall("MessageBox", "ptr", 0, "str", "Text", "str", "Caption", "int", 3)
return


I've added a workaround in v1.1.22.01 for any dialogs under AutoHotkey's control (InputBox, MsgBox, etc.). Specifically, if a Control or Shift key is physically down and neither left/right key is logically down, a key-up is sent.

I documented it in the source code as follows:

Code: [Select all] [Download] GeSHi © Codebox Plus

// If a Control or Shift key is physically down, the dialog somehow recognizes this
// and acts as though the key is logically down even if it really isn't. Logically
// releasing the key before or after the dialog is shown appears to work around the
// issue. If one L/R modifier is logically down and the opposite side is physically
// down, the workaround isn't wanted/needed, because the dialog *should* act like
// the key is down, and it does so until the key is released.
...
/* if LWin or RWin is logically down ... */
// Even though the Win key isn't being released, sending a Shift or Control key-up
// triggers the Start menu. To prevent that, we send the mask key. This has been
// confirmed to apply to #Control, #Shift and the left/right variants.

Note that the issue occurred even if the dialog wasn't triggered by that key (for instance, if the modifiers are blocked by a different hotkey).

If you used either of the workarounds, your script should be unaffected by the update.

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 3 guests