Send("password#123,1) doesn't work in program after compiling .EXE - (Moved)

[Mariog2000]

Running my test code as the .au3 program I'm testing in works fine but when I compile the program as .EXE the password isn't entered correctly AND it's ignoring the 2 "tabs" and "enter".

I know the password isn't correct because it populates the password field with some of the characters (although it looks like less characters than when the .au3 runs) because I can manually submit the password by clicking a logon button and it confirms the password is incorrect.

And even if I did have the password correct, for some reason when compiled, the 2 tabs I'm using to toggle to the "logon" button aren't working.  So it appears I've got 2 issues and not sure if I need to use other commands when compiling a .EXE or where I go from here.  I have tried compiling as 32 and 64 bit along with selecting some of the other options (like "Use UPX") which I don't know what it even does but this is where I've been stuck for going on 4 hours with no luck finding others here or via google so shot in the dark here.  Thanks in advance for any help or ideas I'll post progress as I go I've been using AutoIT going on 2 days now so not exactly a pro yet and sorry if these are dumb/simple issues.

-mario

 

Run("C:\Program Files\VendorApp\VendorApp.exe")
sleep(2000)
Send("userxxx123")
Send("{tab}")
;Set Special Character flag=1 for the # sign in password
Send("password#123,1)
Send("{TAB}")
Send("{TAB}")
Send("{ENTER}")
 

[Melba23]

Moved to the appropriate forum.

Moderation Team

[TheXman]

Aren't you missing the ending double quote (") in the line below?

Send("password#123,1)

 

Edited April 16, 2020 by TheXman

[Mariog2000]

Sorry, yes.  Copy/Paste error when I was stripping out original text but you are correct.  Fortunately it's smart enough not to allow me to compile with mistakes so the real code has the right quotes, etc.  I'm in the process of seeing if there's a better way to send the username and/or password or toggle through the various input fields besides using *tabs* for example.  Definitely finding much more complex ways of doing things but frustrating that the manually testing (F5) runs the script perfectly but compiling breaks it before I can even get into the guts of what I'm trying to do 😞

[Jos]

Try a brief sleep() before the send() of the password to ensure the field has received the focus.

Jos

[Mariog2000]

Great point.  So I thought maybe sending the password before it fully moved to the next field but after adding delays before and after each *send* command I can see there's plenty of time before it tries sending the password string.  What I know for sure now is, whatever is being passed to the password field is not the full password.  When I run this via .au3 script (hitting F5 in the editor) I get 17 * characters (1 for each character of the password).  When I compile this exact same script into an .EXE, it only populates 7 * characters.  I have to assume there's some weird conversion issue that happens to my password text when it's compiled versus run as a script. 

I broke down and used the MouseClick("left",898,511) to select the Logon button for this app so I'm past that (even though sending tabs would be way more flexible in case the window location changes) but for now I'd take any ideas on how to fix during compiling or maybe other ways to send password data to an application.  The application is a thick-client and think a .NET app for what it's worth.

Thanks again for all the quick replies folks

 

[Skysnake]

Hi

Late to the party

try this

Local $testpwd = '#password#123' ; the pasword you want to test
ConsoleWrite(" $testpwd "& $testpwd & @CRLF) ; console output of what that password is
Send( $testpwd,1) ; the send command

Note the Send ($x,1) may be presenting a problem. What happens to that password when you send it with that "1" flag?

[Mariog2000]

Thanks that'll be the first thing I try shortly here and keep you posted!  So without the ,1 flag the # does some weird stuff when running and activates another window and generally just screws up.  With the ,1 everything works perfectly in the editor when testing, but when I go to compile it's definitely not putting the right data in the password field.  Back in a bit thanks again....

[Mariog2000]

Update.  So I replaced the code to update the passwords using the lines provided and not sure what it means but it copies out the exact same number of password characters (7 *'s) as when I compile using the send command with the ,1 flag.  So basically doesn't appear to pass the password character text any differently. 

Also, no matter how many characters I specify for the password it always sends 7 *'s so guessing that's generic.

Something else I noticed for the other problem and wondering if somehow it's related.  To hit the "Logon" button after the password is entered I'm sending *TAB* twice.  When I run the .EXE I see these commands aren't being ignored like I thought but the *SPACE* only highlights to "Logon" button but doesn't appear to send the command long enough.  I've seen somewhere that you may need to use something like Send("{SPACE down}") and specify the command holds down the common for a certain period of time.  So it almost seems like it's just flying through the commands perhaps faster than the program can capture the commands.  

Is there maybe a way I can slow down the passing of these characters?  I'll get back to googling ideas to try that but if anyone cares to help add their 2 cents I'm still at a loss.  Thanks all!

Send("{TAB}")
Send("{TAB}")
Send("{SPACE}")

[TheXman]

20 minutes ago, Mariog2000 said:

Is there maybe a way I can slow down the passing of these characters?

Maybe by carefully reading the help file's documentation of the SEND command?  (HINT: Right before the "Related" section) 

Or by placing a short SLEEP() between them.

;FYI

Send("{TAB}")
Send("{TAB}")
Send("{SPACE}")

;Can also be written as

Send("{TAB 2}{SPACE}")

;OR

Send("{TAB 2}")
Send("{SPACE}")

 

Edited April 17, 2020 by TheXman

[Mariog2000]

Thanks for the shortcuts on the Tab and Space commands always happy to reduce lines.  So I've already been using (Sleep) but not between characters.  Not sure if there's something other than setting sleep to try which was something I was thinking.  For example I found a thread where someone trying to enter arrow keys for a java app actually had to add the commands down and up for each key press because the actual keys were being sent somehow too fast to the application.

So the guy ended up having to use --> Send("{LEFT down}") to press the left arrow down, Sleep(250) to pause, and SEND("{LEFT up}") or something to that affect.  That's what I was more thinking when I asked for slowing the text input down.  

The biggest problem is, I don't have to do anything to the long username I'm entering and it goes in fine so I get the feeling there's something weird with the password field not allowing characters to be entered.  So as I wrote this I though I'd test copying/pasting the password into the application and surprisingly it allowed me to paste in a password without a problem so it doesn't seem like it's particularly finicky from that standpoint.  So... still at a loss as to what's different from the Editor that works perfectly, and whatever happens when it's compiled into a .EXE 😐   Thanks again 

[Mariog2000]

Figured it out!  So I recall our sys admins making it a pain to do anything on our domain controlled laptops including installing apps.  So reading through another thread asking what the difference was between running a script and compiling and that person having issues using "requireAdministrator", I did the opposite knowing we have weird GPO's locking stuff down and sure enough setting "requireAdministrator" before compiling fixed it.

Thanks for everyone replying back I was starting to question how smart it was to try using a tool like this I've never heard of but the user community seems pretty helpful and not a bunch of @$$ holes when someone asks a stupid question especially when that person is clearly not a developer or experienced with the product.  Sure I'll have much dumber problems and questions in the near future but this issue is solved and I have to imagine there are plenty of others that would run into this when admins limit installing executables on their local machines this can't be the first 🙂  Have a great week guys thanks again for the help!

 

-mario