PowerShell is a well-structured system. We hope, our module is no less well-structured: our principle is "C# code that is written once and tested every release is better than people around the world being forced writing the same
in PowerShell many times".
What does this mean? We created hundreds of cmdlets to eliminate the need to write every time those parameters that could be hard-coded in C#.
For example, the following lines of code do the same:
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAControl -ControlType Button -Name 3
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 3
Feel the difference? With such simple hardcoding, you, first, do not need more to type the ControlType parameter (it's consumed by MS UI Automation).
Second, you are given the way to search easily for a cmdlet that would meet your current need:
Get-Command -Module UIA* *Button*
This code displays all the cmdlets the module provides for working with the Button type specifically.
Similarly, to find all cmdlets to perform a click, you may simply ask the module:
Get-Command -Module UIA* *Click*
What's more, we added several aliases to help people who test applications written in various frameworks (Win32/VB6, Windows Forms, WPF, etc) more easily recognize cmdlets - the following cmdlets, for example, are the same (but some names may say more,
regarding the framework your tested app written in):
For those who are interested to dig deeper, this is done by just inheriting one from the other;