Not only in the Get-UIA[ControlType] cmdlet family were introduced improvements. Another veteran, the Get-UIAWindow cmdlet has been modernized.
This is a start place for our experiments:
# there's an application with two forms open Start-Process calc -PassThru | Get-UIAWindow | Get-UIAMenuItem help | Invoke-UIAMenuItemExpand | Get-UIAMenuItem -n about* | Invoke-UIAMenuItemClick;
# using the Get-UIAChildWindow cmdlet Get-UIAWindow -pn calc | Get-UIAChildWindow; # using recursive search for a control of window type (in practice, the same as using the Get-UIAChildWindow cmdlet) Get-UIAWindow -pn calc | Get-UIAControl -ControlType Window;
These samples worked well for us until there were three or more windows open (the main form, the child form and a message box, for example. Another case is the main form and two child forms) or the main form is so complex that consists of two or more forms (dockable parts or a window inside an MMC application).
In such cases, the search for a certain window led to complicated code, especially when forms had the same captions.
Time changed, let’s review new ways of getting a certain window:
# the topmost window (there are no changes with the previous behavior) Get-UIAWindow -pn calc; # all windows of the process(es): Get-UIAWindow -pn calc -Recurse; # all windows with the phrase 'calc' in caption Get-UIAWindow -pn calc -Name *calc*; # all windows with the word 'about' in caption (in fact, it's only the child window) Get-UIAWindow -pn calc -Name *about*; # all windows with ClassName like 'frame' (the main window has Classname == 'CalcFrame') Get-UIAWindow -pn calc -Class *frame*; # all windows with ClassName == '#32770' (the child window has such a standard class name) Get-UIAWindow -pn calc -Class '#32770';
As can be easily seen, one call of the Get-UIAWindow cmdlet could substitute an old-days function of getting the right window.
The only problem in recursive search for windows is the time it could take: if forms are full of controls, the search will relatively slow.