There are two goals the extended elements' object model should achieve:
1) provide the use with an overview what controls are available down the hierarchy
2) simplify coding in certain situations via dotted notation.

To get an overview of controls that are under the current, we simply call a collection:
$wnd = Start-Process calc -PassThru | Get-UiaWindow;
We couldn't use $wnd.Children here as no one button is immediately under the window object. Technically, we could, but the line $wnd.Children.Buttons returns $null, of course.

To get a brief overview of all types of controls available down the hierarchy, we can simply call the list of collections (it may take time if an application is heavily loaded with controls as an app with grids, lists, etc):
$wnd = Start-Process calc -PassThru | Get-UiaWindow;

Getting a collection is not the only feature of the extended elements' object model. We could easily select controls of our interest by using a part of their Name, AutomationId or Class:
$wnd = Start-Process calc -PassThru | Get-UiaWindow;

# returns two buttons, Maximize and Minimize

# narrowing the selection to the Maximize button only
This sample is not very clear as we user here the same property, Name.

The next sample demonstrates how to get buttons by using AutomationId and Name subsequently:
$wnd = Start-Process calc -PassThru | Get-UiaWindow;

# there are ten numeric buttons with AutomationId 13*, from 1 to 10 (or 0 to 9 depending on localization):

# getting the button 2:

# we can check that 2 is 2 by outputting the result:
$wnd.Descendants.Buttons['13*']['2'] | Read-UiaControlName
# or
The same sample via a variable:
$wnd = Start-Process calc -PassThru | Get-UiaWindow;

# getting numeric buttons
$numericButtons = $wnd.Descendants.Buttons['13*']

# getting the button 2

Last edited Jan 13, 2014 at 5:54 PM by apetrovskiy, version 3


No comments yet.