Extraneous control key presses generated by #or ! hotkeys!

AutoHotkey Community
Let's help each other out

FAQ

Memberlist

Profile

Extraneous control key presses generated by #or ! hotkeys!
Goto page Previous 1, 2, 3, 4, 5, 6

AutoHotkey Community Forum Index -> Wish List

View previous topic :: View next topic

Author

Message

Lexikos

Joined: 17 Oct 2006
Posts: 7299
Location: Australia

Posted: Fri Sep 07, 2007 11:45 pm Post subject:

Joy2DWorld wrote:

Quote:

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. Razz

Quote:

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.)

Quote:

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.

Quote:

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:

Code:

#UseHook
+a::return

Code:

#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

Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel

Posted: Sat Sep 08, 2007 7:19 pm Post subject:

lexikos wrote:

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:

Code:

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

produces this output of key history:

Quote:

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

Joined: 17 Oct 2006
Posts: 7299
Location: Australia

Posted: Sun Sep 09, 2007 12:26 am Post subject:

Joy2DWorld wrote:

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.

Quote:

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.

Joy2DWorld previously wrote:

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.

Quote:

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:

Shift is released before the Send operation completes.
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.

Quote:

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.

Quote:

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.

Code:

^+a::send t

Code:

A2 01D d 0.97 Ctrl
A0 02A d 0.06 Shift
41 01E d 0.09 A
A2 01D i u 0.00 Ctrl
A0 02A i u 0.00 Shift
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
41 01E u 0.05 A
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...

Quote:

am not likely to do so again.

That would suit me just fine.

Quote:

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

Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel

Posted: Sun Sep 09, 2007 2:07 am Post subject:

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:

lexikos wrote:

." 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

Quote:

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

Joined: 16 Nov 2009
Posts: 7

Posted: Mon Nov 16, 2009 10:05 am Post subject:

I think this needs a bump, over 2 years later and still not fixed. http://www.autohotkey.com/forum/viewtopic.php?p=310928#310928

Joy2DWorld

Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel

Posted: Mon Nov 16, 2009 5:50 pm Post subject:

HKPolice wrote:

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

http://www.autohotkey.com/forum/viewtopic.php?p=310928#310928

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

Joined: 17 Oct 2006
Posts: 7299
Location: Australia

Posted: Tue Nov 17, 2009 9:05 am Post subject:

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.)

Display posts from previous:

	AutoHotkey Community Forum Index -> Wish List	All times are GMT Goto page Previous 1, 2, 3, 4, 5, 6
Page 6 of 6

You can post new topics in this forum
You can reply to topics in this forum