Forum Discussion
That's a very nice nuclear powered bagel toaster you have written there. ;)
Seriously, though... seems like an overcomplicated bit of code to simply find and click on buttons on a form. I'm sure that descriptive object based programming like this is what happens in tools like Selenium or UFT or other tools... but it's not really necessary for TestComplete.
What happens if you simply do a "record" of your actions? how are things identified using TestComplete's built in object mapping feature aka NameMapping? While I'm not saying throw out your code, doing the record/playback may at least shed some light on how TestComplete "sees" things in order to better adjust your code.
Additionally... is there a particular reason why you need to automate, via UI, the Install Shield wizard for your application? If you are simply needing to install the application, I believe InstallShield installs usually have a command-line functionality that will simplify your world greatly.
I am not installing only one machine, around 20 VM we need to install Application whenver get new build. :(
- Marsha_R6 years agoChampion Level 3
marunachalam wrote:
I am not installing only one machine, around 20 VM we need to install Application whenver get new build. :(
Yes but that's what command line is for. You don't need to have TestComplete click all the buttons. You just need the build to get on there somehow.
- tristaanogre6 years agoEsteemed Contributor
Understood that you need to automate the installation process... However, I question the necessarity of using the UI to do so. You can instantiate a WScript.Shell to fire off a command line to do an installation if the Installer allows it. Likewise, if you have the straight MSI file, you can do it with that. Or, if you have access to the binaries, you could do a simple file copy to get the application installed... all possible to be done via script code in TestComplete across 20+ VMs without having to interact with the UI.
The point: If one method of performing a task is proving difficult, find another way that could be easier.
As it is, the code that you have written makes no distinction between processes found. Basically this.Form().Parent returns the object with handle to ONE of the processes. However, it is possible that may not be the process that, later on, is the one that has your buttons and such on it. Or, one of those other processes maybe overlaying what you're trying to interact with. You make no distinction in that function call to indicate to pick a particular process... the process handle may change so what worked one moment may not another. This code needs to be built out to be more robust to better detect the active window, buttons, etc.
And, as mentioned... that may be more complicated than it is worth, especially if you can achieve the same result (installing the latest build) simply by running a commandline to do so. I would go that route, honestly, rather than pursuing installing via the UI.
Related Content
Recent Discussions
- 16 hours agotramuntana
- 3 days agoSlickRick