Hi there,
I am currently evaluating Eggplant Green and Purple and do my first steps into SenseTalk Scripting.
I am currently running in some strange effects when using WaitFor commands. My intention is to have a script which runs an Vise installer in order to install some items on the SUT. So the code is just a few clickin yes buttons. The SUT is located on a Windows Machine running on a VM Server, so the runtime of the whole situation is rather slow, hence the long wait times for the next images to apear.
My code looks something like this, the numbers are line numbers:
1 Click "WinVista/Installer/buttonNext"
2 Click "WinVista/Installer/buttonNext"
3 Click "WinVista/Installer/buttonYes"
4 WaitFor 60.0,"WinVista/Installer/buttonYes"
5 Click "WinVista/Installer/buttonYes"
6 WaitFor 60.0,"WinVista/Installer/buttonYes"
7 Click "WinVista/Installer/buttonYes"
8 WaitFor 60.0,"WinVista/Installer/buttonYes"
9 Click "WinVista/Installer/buttonYes"
10 WaitFor 60.0,"WinVista/Installer/buttonClose"
11 Click "WinVista/Installer/buttonClose"
12Click "WinVista/closeWindow"
Eggplant prompts me with the following message:
waitfor WinVista/Installer/buttonYes found at (705, 586)
click WinVista/Installer/buttonYes at (705, 586)
Exception WinVista/Installer/buttonClose Unable To Find Any Image On Screen “(“WinVista/Installer/buttonClose”)” within 60.00 seconds
Selection Failed in 0:01:04 Image Not Found waitfor Error - Unable To Find Any Image On Screen “(“WinVista/Installer/buttonClose”)” within 60.00 seconds
I understand the message. But if I look on my SUT then I notice that the installer process is stuck on that point which is processed in line 7. So it seems to me that somehow the script runs “faster” then the actual processes on the SUT?!
My understanding at this point is that this should be prevented by the usage of WaitFor command. None of the isntaller processes between all those Yes clicks need 60 seconds to be processed.
Thanks for an insights on this…
you’ll want to use the smallest possible bit of the button you are looking for ( something with a unique characteristic such as the curve of an “O” in an OK button for example). Especially if you are using it over a number of dialog boxes. I’ve seen a slightly different version of a button used ( developer whim) in dialog boxes.
Since you’re new at this, I’ll also mention the obvious for an installer script…check to be sure you have focus on the dialog, the failure screen capture tool is used to see the exact state of the SUT when the script fails.
The obvious try is to increase the wait time to a much higher number, go have some coffee and come back to see if it’s made it thru.
EP is ideal for installers, I’ve used it to install multiple cross platform software updates on an entire lab full of systems and have encountered a number of installer issues which required script tweaks. An OS update or a background process running on the SUT can make a script toss if the visuals aren’t there.
OK, understood. But I think we can exclude that the script fails to a different “yes” image resulting from the installer. When I proceeed my script at the very point where the message is happening the remaining script commands run smoothly.
Eventually I found the source of my problems. I forfeitet the connections window totally. I used the SUT life monitor window in order to plan my script, but I noticed that the eggplant connection window hangs a lot behind the SUT’s monitor.
So looking at the connections window I can now easily see that the visuals are not there when my script looks for the close button, because it “fires” nearly all “Yes” clicks at the first “Yes” button which appears… so indeeed the script runs faster then the SUT… sigh…
So I guess a Wait command is then the right aproach… or is there some other method… a fixed Wait value is something I had hoped to avoid as long as possible.
try out the “wait until” command, you can get EP to wait until the dialog actually appears, there is a default value I seem to recall, but that’s one method of dealing with latency problems where the screen redraw isn’t so speedy sometimes. You can also alter the execution speed of a script, globally or for a certain section of it. I dealt with older systems in my spread, so I made good use of that command. One of the keys of good script writing is to anticipate possible pitfalls and code them before you start having those annoying middle of script failures.
One of my biggest projects was a script that generated over 20,000 images on a single run. That needs good planning, as the script took 24 hours to run and I didn’t want it wiggin out at 3am.
For an evaluation, I’d be looking for a positive outcome, even if it took a while longer to get there. Turn down the rate of execution in prefs and enjoy watching your computers work for you for a change 