What is the reason to introduce one more UI Automation framework? Especially, when so many represented on the market and this one uses the same techniques.
It happened that a new version of the one big project came up with a completely new user interface. Not a partial change but a wholly rewritten application.
As part of its testing, at the initial stage of the testing cycle, the writing of SetupSuite and TestConsole modules has been started. The first try was attempted with the WASP module. However, soon thereafter it was clear that WASP (usually so useful) is a not proper tool for the task: it works with handles, whereas the setup features selection and grid rows in the application are ‘handless’ objects. Moreover, the actions (MMC 3.0) are also handless.
The second attempt was as removing WASP from the modules and writing a UIAutomation PowerShell module. It was a wrapper to several MS UIAutomation queries and patterns, and something went wrong that time. Maybe, the powershell code was wrong, or the application which scripts have been run in had a bug (it definitely had one in the x86 version that is fixed now, but there’s not been found a dependency) – the truth was as 1) powershell scripts failed to do 2) powershell with embedded C# code failed also 3) C# code ruled. Maybe, it was a bug in a powershell host or a play of threads, the creation of the UIAutomation module has been started at the end of November, 2011.
Now, after two months’ in-the-kitchen work and testing a commercial product with the module (and the module with a commercial product), it is ready to be introduced to the public domain. What things are included into the module:
– getting windows by process name or name (caption, title) – Get-UIAWindow
– getting controls by name, type, automation id or class (less useful) – Get- cmdlets
– invoking such patterns as clicks (InvokePattern), changing text (ValuePattern) and many others (all patterns will bre supported further)
– events (now supported: clicks, editing of text, opening a child window, closing a window) – Register- cmdlets
– Win32 clicks (like in the WASP module)
– exporting data from grids (ConvertFrom- cmdlets)
– waiting for a control to be enabled (Wait- cmdlets)
– exporting some properties of a control (Out- cmdlets)
– saving screenshots on an error or whenever you like (and wherever you like)
– running you custom actions (PowerShell scriptblocks) on any successful operation, any fail or even on an every waiting sleep during the cmdlet’s work
– and several tricks that do the life of software engineer easier.
Among others, to make you life even more easier, there are search capabilities:
– you need to find all the cmdlets that works with the Button control:
simply issue the following piece of code:
Get-Command -Module uia* *Button*
The output informs you.
I welcome you on the project page http://uiautomation.codeplex.com/ and please make your software better!