AHK Mystery

[JDN]

I'm currently having a problem using AHK with Windows 7 but before explaining the problem I'm having, I need to tell you that I have two PCs and this problem only occurs on one of them. Because of that, I fear there may be something about the PC that causes this problem and so you may not be able to replicate the problem on your PC.

I have spent several days isolating this problem and I now have a single AHK script file that contains a single AHK definition. This definition sends the text string "TEST". I defined it that way to demonstrate the definition works OK
and when I invoke it, it does indeed send that correct text string. But, unfortunately, immediately after that, my PC appears to be thrown into a kind of "problem state" where whenever I strike one of a few punctuation keys, my PC produces a key that is entirely different from the key that I actually did strike. I will now show you five of these problem punctuation keys and the characters that are produced in this "problem state". In this "problem state":

/ - forward slash produces the character È
? - question mark produces the character ¿
^ - caret produces the character â
\ - back slash produces the character «
| - vertical bar produces the character ½

Here is the single AHK definition that causes this "problem state". I isolated this problem by creating a single AHK script that contains the following single definition:

^+=::sendinput TEST

-------------------------------------------------------------------------------
Now I want to show you several different ways to define the above hotkey. If you try each of these definitions - one at a time - they all work just fine and when you include all four in the same script, AHK does not complain and it just picks one of them and executes that one - usually the 3rd one from the top. Very strange.

^+=:: sendinput TEST_A
^+:: sendinput TEST_B
^++:: sendinput TEST_C
^+++:: sendinput TEST_D

All four of these definitions can exist in the script at the same time and AHK does not produce any error messages or complain about any duplicate hotkey. Yet all four of these definitions are invoked in exactly the same way - by pressing and holding down both the CTL and SHIFT modifier keys and while continuing to hold them both down you then strike the equal sign. If you include only one of them in a script file, AHK will use that definition with no complaint. This is making it difficult to find the cause of this problem.

By the way, I'm using AHK V1.0.48.05. I'm not sure how to best describe the "keyboard layout". It is a USB keyboard and it's a QWERTY layout. It's a Logitech model K120 keyboard. I opened the Control Panel Keyboard applet but that did not provide me with any additonal information.

I don't understand how all four of these definitions can be invoked in the exact same way and if you have only one of them in a script file, each one works just fine.

[gregster]

A precise problem definition is always very good, but this is a bit long-winded with several paragraphs that are probably totally uninteresting for the people who have the skills to help you - and which are most probably totally irrelevant for the problem. Our AHK gurus for keyboard driver implementation know how to make a shortcut, I am sure, and how to tell if a script is running or to find their desktop. Let's hope you don't deter them from reading. Anyway, I see the good will...

I personally cannot reproduce your problem so far, but I am on Win10 (64 bit and AHK 1.1.28.02 Unicode 64 bit), and I cannot recall reports about such a problem. But that doesn't mean much. I could imagine that there is some other keyboard-related software or driver active on your problem pc that is somehow interfering - so I would look into that.

Something you should add, though, for a meaningful discussion, would be your AHK version (and perhaps the keyboard layout you are using). If you didn't try it yet, you should use the latest AHK version.

Btw, I don't see how these

Code: Select all

^+=:: sendinput TEST_A
^+:: sendinput TEST_B
^++:: sendinput TEST_C
^+++:: sendinput TEST_D

are "all evoked the same way". Sometimes + is the Shift modifier here, and sometimes the actual + key. So, the first three all work for me at the same time. The last one seems to be the same like the next-to-last ("AHK will object"): Ctrl and Shift and +. I am surprised that the last one doesn't throw an error, though. AHK seems to ignore one of the +s.

Edit: Well, I should add that on my german keyboard layout, + and = are on different keys - I assume you are the using the english (US ?) layout, where they share a key... but on my secondary layout, US english, I cannot reproduce your "problem state", either, it seems.

[JDN]

I thank you for your good advice. I had decided yesterday to rewrite this post for several reasons. Among them are several that you mentioned.

When I said that all the hotkeys are invoked in the same way, I was referring to the way in which they are activated. Specifically, you press both the CTL and SHIFT mod keys and while you continue to hold them both down, you then press and release the equal sign. I think it would be real good if we had one way of specifying how we "start" or "invoke" a hotkey and a different way of specifying what the hotkey sends or what it does because I am very mystified to learn that two different hotkeys can both be "invoked" in exactly the same way and they both do the exact same thing but AHK does not consider them to be duplicates.

I wonder if that has anything to do with the different keyboards attached to my two PCs. Both of my PCs have seemingly identical keyboards where the "+" plus sign is found above the "=" equal sign and yet when I include the following four hotkey definitions:

Code: Select all

 ^+::     sendinput  TEST
 ^+=::   sendinput  TEST
 ^++::   sendinput  TEST
 ^+++:: sendinput TEST

All four of the above definitions are invoked in exactly the same way (you press both the CTL and SHIFT keys and while you hold them both down, you then press and release the "=" equal sign). Then you release the CTL and SHIFT keys.
As you can see, all four of the above hotkey definitions perform the exact same function.

But, for some reason, AHK accepts them all and has no problem translating the plain text script file. That sure does seem like an intriguing mystery. I suppose it must depend on the kind of keyboard I'm using because on some keyboards the "+" may not be located directly above the "=".

Very interesting that two hotkeys can both be invoked in the exact same way and do the exact same thing. But they are not duplicates?
I had hoped my problem was caused by this mystery. I just don't understand what is going on. One possibility is that somehow the model of the keyboard currently used has been changed so that Windows does not believe the "+" is found directly above the "=".

I was using AHK V1.0.48.05. But I have now installed the latest version of AHK and found my problem persisted. My keyboard is a USB Logitech K120 keyboard (English or US version) and on both of my keyboards, the plus sign is found directly above the equal sign.

To update this thread, I want to tell you that I have determined - almost certainly - my problem has very little to do with AHK. But is more likely caused by my text editor - NoteTab. For some reason, it appears that Notetab was able to change the model of the keyboard so that Windows believes it is now using a different kind of keyboard than it was previously using.

Would anyone know how I can find out just which kind of keyboard Windows thinks I'm using? I opened the Control Panel and the "keyboard" applet. But I couldn't find any info there on how to determine just what kind of keyboard Windows thinks I'm using. More importantly, how can I instruct Windows to change its view of the kind of keyboard it thinks that it's using?