Keyboard Corruption

[anixon]

I have a Autoit script compiled using the Beta version of the software called say xyz.exe. This script runs perfectly on both a PC and Notebook

computer where AutoIT has been fully installed (Beta). In the script are two #include statments they are #include "Date.au3" and #include

"String.au3"

The program resides in a directory where AutoIT is installed called c:\myprogram\xyz.exe

I have installed the program on a PC which DOES NOT HAVE AutoIT INSTALLED. The executable (xyz.exe) script resides in the directory called c:\myprogram\xyz.exe and the #includes reside in a directory called c:\myprogram\include\date.au3 and string.au3. I have used the ""

delimiters because the script uses the @ScriptDir Function.

The executable script launches without a problem however the Inputbox will not take input from the keyboard 'M' returns a O and ""a" as a 6.

If I launch Word or Notebook I get the same problem with the same keystrokes returning the same wrong characters.

The only way I have been able to resolve this issue is to Restore the PC to a date time prior to downloading my Script which gives me back

the correct Keyboard character assignments.

To establish that the problem might be related to my script I have downloaded it again and the problem simply re-appeared with the keyboaqrd

producing exactly the same result 'M' is returned as a O and 'a' as a 6.

Deleting the scripts and restoring the PC again to an early date time returned the Keyboard to their correct character assignments.

I am running Windows XP Pro which has installed all published Microsoft Updates as at 20th January 2007.

It may simply be a co-incidence however it strongly appears to be related to my script running on a PC where AutoIT has not been installed.

Can anyone advise how this problem (if it is AutoIT related) be resolved?

Cheers Ant...

[Uten]

Hi @anixon,

As of writing I think the stable release is the latest release (v3.2.2.0). So you should probably upgrade to "stable"..

Not that I think it will solve your weird problem. I have had the same problem with a keyboard before. Spilling coke on a keyboard can do "magic" to how it operates. Never heard that it is possible to use restore to get it working again though.

Seriously, as long as you don't use FileInstall (dllcall) or the COM interface in your script it should be standalone. The #include statements does not change this as the files indicated in your #include statements are included in the "compiled" exe. (you can observe this if you decompile your scritp with exe2aut.exe found in the autoit\extras folder.

Could you try out a minimal script on the computer with a problem?

Just a simple inputbox statement and see what you get?

Maybe you should even consider to post you script? You newer know someone might be able to spot some typoes in it?

Happy Scripting

EDIT: Typoe

Edited January 20, 2007 by Uten

[anixon]

Hi @anixon,

As of writing I think the stable release is the latest release (v3.2.2.0). So you should probably upgrade to "stable"..

Not that I think it will solve your weird problem. I have had the same problem with a keyboard before. Spilling coke on a keyboard can do "magic" to how it operates. Never heard that it is possible to use restore to get it working again though.

Seriously, as long as you don't use FileInstall (dllcall) or the COM interface in your script it should be standalone. The #include statements does not change this as the files indicated in your #include statements are included in the "compiled" exe. (you can observe this if you decompile your scritp with exe2aut.exe found in the autoit\extras folder.

Could you try out a minimal script on the computer with a problem?

Just a simple inputbox statement and see what you get?

Maybe you should even consider to post you script? You newer know someone might be able to spot some typoes in it?

Happy Scripting

EDIT: Typoe

Thanks for the information. I have check and I am running version 3.2.2.0 (Public version of Beta). The script is not using any dllcalls or the COM interface it is basically stand-alone. My daughter has an IBM Thinkpad R52 exactly the same as my Wife. My daughter's Notebook does not have AutoIT installed on it but my Wifes does. It does not work on my daughters but works fine on my wifes. On the first installation I went through the Keyboard driver upgrade procedure which

did not resolve the problem. Both machines are brand new and I am sure nothing has been spilt on the keyboard. I have fully tested the script on my wifes Notebook and it works perfectly. I am pretty sure that the problem is not related to a typo issue as the Input process works fine with the exception of the daughters PC. Have even scanned for a Virus with the latest signatures issued by McAfee resulted in nothing. What I am going to do is dismount AutoIT off my Wifes Notebook and see if I get the same problem. I will post the results tomorrow. Cheers Ant...

[Uten]

And there is not some weired FN+NUMPAD lock on your daughters computer? I did that once in a stresfull situation :">

[anixon]

And there is not some weired FN+NUMPAD lock on your daughters computer? I did that once in a stresfull situation :">

You are a legend you have provided the information which has helped me to resolve the problem. Thank you very much.

For your information the script was written on a PC with a numeric keypad the script contains piece of code to set the numlock to on

because a lot of the input is numeric. This was to insure that the keypad was correctly configured ready for the user.

Off course the Notebook does not have a seperate Keypad and if you perform a Shift + Numlock you get the following result for

Now is the time..

N6w 5s the t5oe

Which is of course what you get on a Notebook where the Numlock is on which simply super imposes the keypad over the alpha keys

so "O" becomes 6 and "I" becomes 5 etc.

Boy do I feel sheepish I'm only 61 with so much to learn and so little time.

Anyway I can fix this in the scripts xyz.ini file to allow the code to run or not run dependant upon whether the Desktop has a keypad or not.

The new code therefore would look like this:

; Turn on Keypads Numlock

;

$Keypad = IniRead(@ScriptDir&"\myprogram.ini", "Keypad", "numlock", "0")

If $Keypad = 1 then

Send("{NUMLOCK on}")

Else

Send("{NUMLOCK off}")

EndIf

Once again thank you very much and all the best Anthony

[Uten]

Just a pleasure..

Happy Scripting