Send not functioning as advertised

[ChipsNSalsa]

I'm running v7.5.6 32-bit and 64-bit.

An old script that used to work no longer does. The script had:

Code: Select all

Send, connect 192.168.52.233 --name=admin --password=mypassword;{Enter}

The results in the console application it's sending to are now:

connect 192.168.52.233 --name)admin --password)mypassword<

This used to work. I've even tried SendRaw and get the same results. The only thing that works for me now is:

Code: Select all

Send, connect 192.168.52.233 --name{asc 0061}admin --password{asc 0061}mypassword{asc 0059}{Enter}

That shouldn't be necessary. The original code using the = and ; should work based on the rules I've read for the Send function.

[jeeswg]

- You could try Send {Text} (which requires AHK v1.1.27+).
- Did you change PC or AHK version number?
- Which AHK versions before/after?
- What is 'v7.5.6'? AHK has versions 1.0, 1.1 and 2.0 (alpha).

[ChipsNSalsa]

Wow! I messed up the versions reported bad. I was looking at my Notepad++ versions. Sorry... Long day.

I'm running Autohotkey Unicode 32-bit 1.1.14.01. I do not recall which version it was actually working in. I'll try an upgrade and see if the problem still exists.

[ChipsNSalsa]

Running 1.1.29.1 now. Same results. Tried ANSI 32-bit, Unicode 32-bit, and Unicode 64-bit.

[jeeswg]

- Even with Send {Text}? E.g. Send, {Text}my text
- Did you try Send/SendInput?

[ChipsNSalsa]

Just tried:

Code: Select all

Send, {text}connect 192.168.52.233 --name=admin --password=mypassword;`r`n

and it does work. The = and ; are issued. I guess my point is it shouldn't be required as neither = or ; are "special keys" or reserved in the context of Send.

[lexikos]

Consider why there are multiple Send modes and parameters such as key delay and duration.

Automation via keyboard commands is fundamentally imperfect - the keyboard state is shared between the user and programs, and there are no guarantees as to how the target application will respond to keyboard events. On top of that, there are limitations to the functions that Windows provides. Determining the keyboard layout of a window, converting characters to keycodes according to the layout, and sending keys must all be done through these functions.

In this case, I can only assume that there is a keyboard layout mismatch between what Windows reports for your console window and what the application is actually using to translate keycodes to characters. In other words, = is translated to the keycode appropriate for the layout reported for that window, but the application interprets the keycode as ) instead. Using {text} works because it sends characters by character code, not keycode. It is not used by default because it does not work universally for everything that scripts use Send for (and even if it worked, any change in behaviour carries the risk of breaking scripts).

I guess my point is it shouldn't be required as neither = or ; are "special keys" or reserved in the context of Send.

It is not required, and is working fine for me - and presumably, everyone but you. What is different about your console application or system setup?

[ChipsNSalsa]

I narrowed this down. I'm running Microsoft Windows 10 Pro (10.0.16299 Build 16299) 64-bit. I normally have a second language, Español (México), installed but inactive. The Keyboard for the language is listed as Latin America QWERTY. My default/active language is English (United Sates) with a US QWERTY keyboard. With the English (United Sates) language and a US QWERTY keyboard active and the Español (México) language and Latin America QWERTY keyboard simply installed but inactive, I see the errant behavior. If I remove the second language and leave only the English (United Sates) language it works as it should. Obviously AutoHotKey is using the Latin America QWERTY keyboard layout when it's installed yet inactive. I don't know if it's windows fault for reporting the wrong keyboard as being active to AutoHotKey or AutoKotKey's fault for thinking the wrong keyboard is active. And my console application is not alone. I can launch the cmd.exe console and see the same behavior.

Code: Select all

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

Run, cmd.exe
WinWait, Command Prompt
Send, connect 192.168.52.233 --name=admin --password=mypassword;