Tag Archives: MenuItem
Task: automate combo box selection.
Task #2: provide a homework helping to learn the control.
Requirements: describe both getting the selection and selecting list items.
Solution: below is the preparation (services.msc is already running, select a service, open the context menu, click Properties):
Get-UIAWindow -Name Services | ` Get-UIADataGrid | ` Get-UIADataItem -Name Alerter | ` Invoke-UIAControlContextMenu | ` Get-UIAMenuItem -Name Properties | ` Invoke-UIAMenuItemClick;
If you are sitting against a Windows 7 box, select for our test another service, for example, BranchCache.
Now the combo box can be seen. It has three or four values (I’m again doing the testing on a Windows XP box as I care about working on older and the newest operating systems): Automatic, Manual, and Disabled. There might or mightn’t be two ‘Automatic…’ items.
How to get what is selected now? Do so:
$((Get-UIAWindow -p mmc | Get-UIAComboBox | Get-UIAComboBoxSelection)).Current
Now, is there a way to set a selection? Who roared ‘SetFocus; SendKeys’? Shut up, it’s not a sport but a torture. If a control is healthy and developers’ hands are sewn directly to shoulders, we can and we must use patterns.
Get-UIAWindow -p mmc | ` Get-UIAComboBox | ` Invoke-UIAComboBoxExpand | ` Get-UIAList | ` Get-UIAListItem -Name Automatic | ` Invoke-UIAListItemSelectItem -ItemName Automatic | ` Invoke-UIAListItemClick;
Too long? Let’s shortenize:
Get-UIAWindow -p mmc | ` Get-UIAComboBox | ` Invoke-UIAComboBoxExpand | ` Get-UIAListItem -Name Automatic | ` Invoke-UIAListItemSelectItem -ItemName Automatic | ` Invoke-UIAListItemClick;
We managed to delete only the Get-UIAList cmdlet. Why?
1) All the Get- cmdlets can perform search from the point they’ve been given with. Given a window, a childwindow or a control, from any of that start, a Get- cmdlet (excluding Get-UIAWindow as it does not have the -InputObject parameter) can continue the search down the Automation tree.
2) All the Invoke- (and pattern-cmdlets Get- and Set- like Get-UIAComboBoxSelection. Recognize them in a way: Get/Set-UIA[ControlType][Pattern name or abbreviation]) cmdlets can’t perform any search. They should be fed with a pipeline from a Get- cmdlet or a cmdlet that passed thru (-PassThru’ed) the object of the AutomationElement type.
To shortenize even more, you may cut out the first call, Get-UIAWindow (as it’s always stored in the [UIAutomation.CurrentData]::CurrentWindow variable), but be very attentively doing so: if you/your test Get-s a window (the main or an active child), closes it and tries to work with subsequent calls of Get-UIAWindow, error definitely will appear.
Homework: practisize working with the combo box, try another values, get the selection (I suppose that you know what is the difference between the selected list item and the selected list item that is braced inside the dotted box), save selection to a file, change selection, read it back from the file you’ve created, set the saved selection to the combo box, and do it until a new post got published. 🙂
Task: demonstrate return values.
Task #2: provide a field for learning the module.
Requirements: provide examples with two types of return values.
Solution: run the following code:
(Get-UIAWindow -ProcessName mmc | ` Get-UIAMenuItem -Name File | ` Invoke-UIAMenuItemClick).Current.Name
Not surprisingly, this code returned the name of the menu item selected. By default, all the cmdlets where it’s possible return the object of AutomationElement type.
However, you may change this behavior. If so, this code would return $true in success case and $false in case of an error, timeout, and cetera.
It’s needed rarely, because the if statement works well with $true/$false as well as the object/$null pair.
If you wish, you can change the code in the way:
Get-UIAWindow -ProcessName mmc | ` Get-UIAMenuItem -Name File | ` Invoke-UIAMenuItemClick -PassThru:$false;
Homework: experiment with return values. Try cmdlets one by one, which values they return with and without -PassThru.