Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Extraneous control key presses generated by #or ! hotkeys!


  • Please log in to reply
82 replies to this topic
Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

I'm certain AutoHotkey already has code to prevent accidental triggering of the language hotkeys (but not explicit triggering - i.e. Send {LAlt down}{Shift}{LAlt up}.)


unfortunately, and as is the subject of this thread.. your certainty is in error.

No, you are incorrect. I said I am certain there is code to prevent it, not that that code works. :p

iirc, the control keypresses aren't sent if Shift is already down. (Edit: on second thought, that may only be for the Win key.)

incorrect. they are in *both* cases.

I just did a quick test, and control is not sent for a Win+Shift hotkey using the hook (like +#a or *#a.)

please look at the thread carefully. you will see it is not.

My point is it isn't random. There is a reason for everything, usually a good reason.

Any hooked hotkey or #IfWinActive hotkey that has "shift" as part of the hotkey (ie. "+"), switches the user's input langauge is the shift key is the last key released.

These don't:
#UseHook
+a::return
#UseHook
#+a::return
So clearly your statement is incorrect. (I added an input language and set the shortcut to Ctrl+Shift to test this. I also had a key history script running, showing no control keypresses were generated.)

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006

So clearly your statement is incorrect. (I added an input language and set the shortcut to Ctrl+Shift to test this. I also had a key history script running, showing no control keypresses were generated.)


I can't believe am wasting my time even answering you on this.

am not likely to do so again.


my friend, YOUR conclusions are in error.


I said, the controls are generated in a random-mess fashion, sometimes you see them, sometimes you don't.

you didn't seem to get that point.

with some hotkeys, such as control+Shift + X you will switch langage with ever activation is you send anything in your hotkey, and as is natural for most, release the control before you release the shift.


with others, such as Win+Shift, the control is generated depending on many factors.

you did it once, a few times (?) and didn't see control. therefore you concluded i was wrong... great logic.

this script:
SetTitleMatchMode, Regex
#Ifwinactive  Test
#+A:: send ok twhat is your p

produces this output of key history:

53 01F i d 0.02 S
53 01F i u 0.03 S
20 039 i d 0.02 Space
20 039 i u 0.00 Space
59 015 i d 0.02 Y
59 015 i u 0.00 Y
4F 018 i d 0.02 O
4F 018 i u 0.00 O
55 016 i d 0.02 U
55 016 i u 0.00 U
52 013 i d 0.02 R
52 013 i u 0.00 R
20 039 i d 0.02 Space
20 039 i u 0.00 Space
50 019 i d 0.03 P
50 019 i u 0.00 P
A2 01D i d 0.02 Ctrl
5B 15B i d 0.00 Left Windows
A2 01D i u 0.00 Ctrl
5B 15B u 0.05 Left Windows


notice the control key which is generated.

again, there a many factors... such as order of key release. With the shift+windows, if shift is released last, usually no control is generated, but when windows is released last (and depending on timing of release, etc. etc.) then as you see here... the control *IS* often generated.


and all of this is a side show, if you read carefully the thread, you see MANY, very REAL, very COMMON instances of control and multi-control generation by AHK that conflicts with man windows system functions and 3rd party programs. THAT is the point. this sideline, about an odd-ball key sequence Shift-Win and whether it generates controls (it does), really is NOT the point, certainly not mine.
Joyce Jamce

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

I said, the controls are generated in a random-mess fashion, sometimes you see them, sometimes you don't.

you didn't seem to get that point.

Oh, I heard you all right. I said I have never seen this "randomness." Corrupt and I have both said it seems fairly consistent to us.

with some hotkeys, such as control+Shift + X you will switch langage with ever activation is you send anything in your hotkey, and as is natural for most, release the control before you release the shift.

That is NOT what you said.

Any hooked hotkey or #IfWinActive hotkey that has "shift" as part of the hotkey (ie. "+"), switches the user's input langauge is the shift key is the last key released.

You did NOT say any hooked hotkey that sends keystrokes. The majority of mine do not. I did not say the control keypresses are never sent, I said your statement is incorrect - i.e. not just "any" hotkey will cause that behaviour. That is clear from my tests.

with others, such as Win+Shift, the control is generated depending on many factors.

Trying your example for a while, those "many factors" seem to be:[*:2fe6agbs]Shift is released before the Send operation completes.
[*:2fe6agbs]Win is not released.Also, it isn't a raw control keypress - it's Ctrl+Win. They do not trigger the Ctrl+Shift language switching shortcut as you previously implied.

with some hotkeys, such as control+Shift + X you will switch langage with ever activation is you send anything in your hotkey,

That is, at least, a good point.

and as is natural for most, release the control before you release the shift.

That doesn't seem to be necessary. It'll trigger the language switch even if you don't release the control key.
^+a::send t
A2  01D	 	d	0.97	Ctrl           	
A0  02A	 	d	0.06	Shift          	
[color=orange]41  01E	 	d	0.09	A     [/color]         	
[color=red]A2  01D	i	u	0.00	Ctrl           	
A0  02A	i	u	0.00	Shift          	[/color]
54  014	i	d	0.00	T              	
54  014	i	u	0.00	T              	
A2  01D	i	d	0.02	Ctrl           	
A0  02A	i	d	0.00	Shift          	
A2  01D	 	u	0.11	Ctrl           	
[color=orange]41  01E	 	u	0.05	A              	[/color]
A0  02A	 	u	0.05	Shift
(The A keypresses are only seen if #UseHook isn't used.)

Unfortunately, I don't see a way around this. Ctrl and Shift must be artificially released during the send for the keystrokes to not be Ctrl+Shifted. I suppose you could manually or automatically (via script) switch the language back afterwards, but that mightn't work, since the send itself might be in the wrong language...

am not likely to do so again.

That would suit me just fine.

my friend, YOUR conclusions are in error.

No, my conclusions are based on the literal meaning of what YOU said. If you said things inaccurately or in a way that you did not mean, that's not my problem.

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006
if not obvious, this is *not* directly the issue raised in this thread (ie. shift-Alt does the same effect, but should not... control not involved in the hotkey, anyhow) the problem you point to does deserve comment:

." Unfortunately, I don't see a way around this. Ctrl and Shift must be artificially released during the send for the keystrokes to not be Ctrl+Shifted.


the directed rudeness of your post aside, (perhaps you understood

I can't believe am wasting my time even answering you on this.

to be about YOU, it was not. (and not that if it was, that would justify rudeness, but anyhow). It was about THIS, that there is a problem, a simple solution. And for me, the continued existence of a problem and simple solution, is well.. unjoyful.

and without much hope of any productive outcome,

simply note:

injection of the 0xFF u/d sequence after the shift-d control-d seems to solve the language change issue. (obviously that should be an AHK option to insure no scripts break, etc. allow for testing, etc.)
Joyce Jamce

HKPolice
  • Members
  • 7 posts
  • Last active: Nov 16 2009 11:04 PM
  • Joined: 16 Nov 2009
I think this needs a bump, over 2 years later and still not fixed.

<!-- m -->http://www.autohotke... ... 928#310928<!-- m -->

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006

I think this needs a bump, over 2 years later and still not fixed.

<!-- m -->http://www.autohotke... ... 928#310928<!-- m -->



since only a set group of users suffer from this... am not sure is actually recognized as a problem for fixing.


although, would be nice to have fix included (at least as an option) in standard AHK build...


perhaps with issues now raised in general users game playing, time may be right to allow option for alternate menu suppression option ?
Joyce Jamce

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I've added a #MenuMaskKey directive to AutoHotkey_L to change which virtual key is used. For code simplicity and because it seems unlikely to be of use, it can't be disabled completely. I suggest using an unassigned keycode such as vk07. (vkFF also works, though it is outside the range of values that Microsoft deems valid.)

joshieecs
  • Members
  • 1 posts
  • Last active: May 10 2015 06:02 PM
  • Joined: 29 Mar 2015

THANK YOU for adding the #MenuMaskKey directive. I play a game (Elder Scrolls Online), whose internal keybindings do not allow for modifier keys. I remapped modified some key combinations to single function keys above F12 using ahk, and it works great. However before I read this whole thread and came to your last post, the phantom Control key presses were erratically activating the Ctrl ability in the game (stealth mode) erratically, making it unplayable. But using #MenuMaskKey vk07, eveything works just great (after two hours of trying to figure out why my hotkey kept putting me into stealth! lol). 

 

So thanks, for this and for all your work on the project. For what it's worth, I got a kick out of the whole dialogue between Joy2DWorld and who I assume is a former developer. I've been that frustrated user, as he was, so many times. It's nice to see a story like this have a happy ending, even six years later. Maybe not all our struggles are in vain, even if they seem like it at the time.