Jump to content

Run Loop when installing from network.


Recommended Posts

I think this only happens when i'm running the compiled EXE from the same directory as the called exe, however i have been unable to pin down exactly where it does and doesnt work trhougout all my tweakings. Basically when I try to run this a lot of the time it just calls the compiled script over and over. Other times it works just fine. I've tried running it from wherever, that doesnt seem to be the issue.

Run ( "\\util\install\toad\Toad Freeware Install.exe","c:\")
WinWait("Toad for Oracle Freeware Installation","Welcome!")
ControlClick("Toad for Oracle Freeware Installation","&Next >",4)
WinWait("Toad for Oracle Freeware Installation","< &Back")
ControlClick("Toad for Oracle Freeware Installation","&Next >",3)
WinWait("Toad for Oracle Freeware Installation","Select Destination Directory for Client Install")
ControlClick("Toad for Oracle Freeware Installation","&Next >",3)
WinWait("Toad for Oracle Freeware Installation","Backup Replaced Files?")
ControlClick("Toad for Oracle Freeware Installation","&Next >",3)
WinWait("Toad for Oracle Freeware Installation","Select Backup Directory for Client Install")
ControlClick("Toad for Oracle Freeware Installation","&Next >",3)
WinWait("Toad for Oracle Freeware Installation","Ready to Install!")
ControlClick("Toad for Oracle Freeware Installation","&Next >",3)
Winwait("Create TOAD Desktop Icon?")
ControlClick("Create TOAD Desktop Icon?","&Yes",5)
WinWait("Toad for Oracle Freeware Installation","Installation Complete!")
ControlClick("Toad for Oracle Freeware Installation","View ReadMe",10)
ControlClick("Toad for Oracle Freeware Installation","Start Toad for Oracle FREEWARE",9)
ControlClick("Toad for Oracle Freeware Installation","&Finish",3)
Exit

Thanks.

Link to comment
Share on other sites

Basically when I try to run this a lot of the time it just calls the compiled script over and over.

What do you mean it calls the compiled script over and over? Do you mean it hangs?

I often have to add sleep(2000) statements between commands in order to slow down the command stream. Correct me if I'm wrong, but what I think can happen is that your "winwait" command sees the window it's waiting for; then your ControlClick sends its command; then while the program itself is absorbing the ControlClick, the next winwait and Controlclick fire off and the program itself is not yet ready. So, try adding Sleep(2000)'s after each ControlClick for debugging and remove them as possible...

Edited by jefhal
...by the way, it's pronounced: "JIF"... Bob Berry --- inventor of the GIF format
Link to comment
Share on other sites

I take it you named the compiled script "Toad Freeware Install.exe"?

Look at Run() in your script, your telling it to run it again, then the new one that opens is told to run it again, and again and again.

Why do you want to call your compiled .exe a second time anyway?

The variation you have from when it does the above and when it doesn't, I am guessing, that is perhaps you might be running the script, ie. .au3 file, and not the.exe

qq

Link to comment
Share on other sites

i dont, i compiled the script to be Toad.exe, and Toad Freeware Install.exe is the normal install file. I'm just automating the installation of it. The strange thing is the script never even gets a chance to run the install file while its calling so many copies of itself.

i'm testing all situations of running the script and that stuff to try to isolate the problem.

Edited by Swimming_BIrd
Link to comment
Share on other sites

i dont, i compiled the script to be Toad.exe, and Toad Freeware Install.exe is the normal install file. I'm just automating the installation of it. The strange thing is the script never even gets a chance to run the install file while its calling so many copies of itself.

i'm testing all situations of running the script and that stuff to try to isolate the problem.

<{POST_SNAPBACK}>

i don't see anywhere in here where you have a run statement calling 'toad.exe' so i'm not sure how it could be recursively calling itself unless there is more code you're not showing us. and you look to be using all the right functions to avoid errant clicks and sends, with the controlclick()'s and winwait()'s. is there more code to the script?

<added after edit>

Another thing that i've done before myself, is making changes to the .au3, then running the exe, forgetting to recompile. especially since i've started using scite, because i'll already have an .exe from previous compile that i'm troubleshooting, and i'll get it working using {f5} to run au3, but i'll forget to {f7} to create new exe...any chance you're guilty of that also?

Edited by cameronsdad
Link to comment
Share on other sites

naw, i have re compiled over and over just to make sure. i'm gonna try running both the scipt and compiled exe from a number of different locations i an attempt to pin down the issue

<{POST_SNAPBACK}>

the location "shouldn't" affect the way the script is running, but it still doesn't change the fact that there don't appear to be any statements that could in any way accidentally run the wrong thing. And if it is running that differently when compiled rather than being run as an .au3, that could be a different issue. Are you sure this is the full code listing?
Link to comment
Share on other sites

Also is it the script or the installation that you put in the temp directory?

I dont recall seeing an answer to whether or not there is more code?

JS

AutoIt Links

File-String Hash Plugin Updated! 04-02-2008 Plugins have been discontinued. I just found out.

ComputerGetInfo UDF's Updated! 11-23-2006

External Links

Vortex Revolutions Engineer / Inventor (Web, Desktop, and Mobile Applications, Hardware Gizmos, Consulting, and more)

Link to comment
Share on other sites

when i removed the spaces from the called program the script ran fine.

there was no other lines in the script, what i posted was complete.

and the script was runnin ogver and over and the installation file wasnt running at all.

while i fixed it will this happen whenever i have spaces in a run command?

Edited by Swimming_BIrd
Link to comment
Share on other sites

when i removed the spaces from the called program the script ran fine.

there was no other lines in the script, what i posted was complete.

and the script was runnin ogver and over and the installation file wasnt running at all.

while i fixed it will this happen whenever i have spaces in a run command?

<{POST_SNAPBACK}>

i'm not able to re-create this, but i use spaces in run()'s all the time, any time i have something in 'program files'. one thing that i could see as a possible bug if removing spaces fixing the issue... your spaces were in your actual filename, not the path, and if i remember correctly, the first word of your filename was the same as the same as the name of your script. if a space causes the interpreter to ignore the rest of the filename except the extension, that's something that would definitely need to be corrected... i'm going to do some testing to see if i can re-create w/ similar circumstances.
Link to comment
Share on other sites

i'm not able to re-create this, but i use spaces in run()'s all the time, any time i have something in 'program files'.  one thing that i could see as a possible bug if removing spaces fixing the issue... your spaces were in your actual filename, not the path, and if i remember correctly, the first word of your filename was the same as the same as the name of your script.  if a space causes the interpreter to ignore the rest of the filename except the extension, that's something that would definitely need to be corrected... i'm going to do some testing to see if i can re-create w/ similar circumstances.

<{POST_SNAPBACK}>

yes, i think this definitely qualifies as a bug... here's what i did... i created 2 scripts

'test.exe' and 'test 2.exe'

test.exe contains:

run("test 2.exe")
msgbox(0,"name","caller")

and 'test 2.exe' contains:

msgbox(0,"name","successful call")

with both files in the same directory, sure enough a loop that instantly fills my systray with icons all the way to the start button from the calling app running repeatedly... maybe you should post something in the bug submit forum... that is not with the beta though... will recompile 'test.exe' and reply here if i get different results...

Link to comment
Share on other sites

yes, i think this definitely qualifies as a bug... here's what i did... i created 2 scripts

'test.exe' and 'test 2.exe'

test.exe contains:

run("test 2.exe")
msgbox(0,"name","caller")

and 'test 2.exe' contains:

msgbox(0,"name","successful call")

with both files in the same directory, sure enough a loop that instantly fills my systray with icons all the way to the start button from the calling app running repeatedly...  maybe you should post something in the bug submit forum... that is not with the beta though... will recompile 'test.exe' and reply here if i get different results...

<{POST_SNAPBACK}>

same result...
Link to comment
Share on other sites

in post #8 i said to rename the exe file, could of saved alot of grief from then on.

<{POST_SNAPBACK}>

very true, if he'd listened to you his prob would have been solved alot faster, but that still leaves the issue that the filename in the RUN() function is being truncated either at run time or compile time...
Link to comment
Share on other sites

very true, if he'd listened to you his prob would have been solved alot faster, but that still leaves the issue that the filename in the RUN() function is being truncated either at run time or compile time...

<{POST_SNAPBACK}>

Its not a bug. I'm not going to delve into the plethora of possible ways that strings must be formatted for the run command, but its not a bug.

Edit: Spelling error fixed.

Edited by Valik
Link to comment
Share on other sites

Its not a bug.  I'm not going to delve into the plethora of possible ways that strings must be formatted for the run command, but its not a bug.

Edit: Spelling error fixed.

<{POST_SNAPBACK}>

i had started writing up this big long response about how if a literal string is not being passed literally, it must be a bug. The first line of that post was about how i would not presume to think my understanding of anything autoit related is on the same level as yours, and then i proved that statement. i created a file named test.exe that just had:

msgbox(0,"oops","you're an idiot")
i then went to command prompt and tried to run 'test 2.exe', expecting to see a file/command not found error. instead, as you would have probably been able to predict Valik, my computer called me an idiot. Apparently the interpreter that windows uses is the offending string chopper, not the compiler for autoit, hence: no bug. So now i actually understand how you can say no bug. I'm sure i could have kept the explanation to myself and avoided looking foolish for almost questioning Valik, but i thought i may be sparing someone else from looking silly arguing that it's a bug...
Link to comment
Share on other sites

If the path is not fully qualified (C:\Path\To\Binary.exe) then it will search in the current working directory for an executable file matching the first argument; all other parameters will be passed as arguments to the program. There are 2 solutions; either specify the full qualified path to the executable or surround the name of the executable with quotes. For example, "test 2.exe" would become '"test 2.exe"'. Then it will be properly passed as a single parameter.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...