Tag Archives: ControlType.MenuItem

Daily automation: a few windows in parallel


At work, an interesting question was raised: is it possible to work with several windows in parallel if their processes are run under various users? Yes, it surely is.

Task: use UIAutomation to get windows of AUTs that are run under various users.

Requirements: demonstrate how to use the technique and how to determine which window might cause a problem.

Solution: the first example is simple and demonstrates how to handle several windows:

Set-StrictMode -Version Latest;
ipmo [path]\UIAutomation.dll
Start-Process calc;
Start-Process calc;
Start-Process calc;
Start-Process calc;
Get-UIAWindow -ProcessName calc | Get-UIAButton -Name 1 | Invoke-UIAButtonClick | Read-UIAControlName
Get-UIAWindow -ProcessName calc | Get-UIAMenuItem -n vi* | Invoke-UIAMenuItemExpand | Get-UIAMenuItem -n scien* | Invoke-UIAMenuItemClick

The sample starts the foursome of calculators, gets them all, clicks the 1 button and changes application mode to the Scientific one.

There is no difficulty with windows run under several user accounts while your test process (i.e., powershell) is running with at least equal or higher privileges.

Now, we’ll start calc under two different user accounts (credentials are not provided to the public domain just for you not locking your accounts ;):

Set-StrictMode -Version Latest;
ipmo [path]\UIAutomation.dll;
(Start-Process calc -Credential (Get-Credential) -PassThru).Id
(Start-Process calc -Credential (Get-Credential) -PassThru).Id
# Here, we are writing up numbers to a paper
Get-UIAWindow -ProcessId 5924,6076 | Get-UIAMenuItem -Name vi* | Invoke-UIAMenuItemExpand | Get-UIAMenuItem -Name scien* | Invoke-UIAMenuItemClick

This works, but the sample is not friendly to use: you need to store process ids. Okay, below is a better one-liner:

Set-StrictMode -Version Latest;
ipmo [path]\UIAutomation.dll;
@((Start-Process calc -Credential (Get-Credential) -PassThru).Id; (Start-Process calc -Credential (Get-Credential) -PassThru).Id) | %{ Get-UIAWindow -ProcessId $_ | Get-UIAMenuItem -Name vi* | Invoke-UIAMenuItemExpand | Get-UIAMenuItem -Name stat* | Invoke-UIAMenuItemClick; }

Finally, how to learn which window failed? For example, by defining a counting variable that will increment every window and point to an element of the windows array.

Daily automation: how to test help files. Part 2. Better navigation


Today’s post is a next version of the recently posted HelpWalker.ps1. This version (HelpWalker2.ps1) brought to us the following improvements:

  • scroll down, in order to make nodes visible. The Invoke-UIAControlClick cmdlet uses Win32 API functions to perform clicks, and these functions are bound to the visible area to be working
  • scroll horizontally, so that the middle of some long tree node names are put geometrically in the tree area. Otherwise, it was seen as if click was send not to a node but to a form splitter or even to a right-side page.

Task: improve the script that all the clicks, especially done in the lower area of the tree, get working.

Requirements: the script should walk through any number of tree nodes, independently of how long their names are.

Solution: below is the script that walks through all nodes with no exception:

####################################################################################################
# Script name: HelpWalker2.ps1
# Description: demonstrates how to work with the Invoke-UIATreeItemScrollItem cmdlet
# Copyright: http://SoftwareTestingUsingPowerShell.com, 2012
####################################################################################################

param(
 [string]$FileName,
 [string]$AppTitle,
 [string]$HelpTitle
 )
Set-StrictMode -Version Latest
cls;

#ipmo $global:uiautomationModule;

if ($FileName.Length -eq 0 -or $AppTitle.Length -eq 0 -or $HelpTitle.Length -eq 0) {
 Write-Host "Please specify parameters as .\HelpWakler2.ps1 app_file_name application_title help_title";
 exit;
}

# set a small delay between nodes
# because the refresh of each page should take time
[UIAutomation.Preferences]::OnSuccessDelay = 100;

# create our enum object
[PSObject]$testNames = New-Object PSObject;
$testNames | `
 Add-Member -MemberType NoteProperty -Name AppTitle -Value $AppTitle -PassThru | `
 Add-Member -MemberType NoteProperty -Name HelpTitle -Value $HelpTitle -PassThru | `
 Add-Member -MemberType NoteProperty -Name AppName -Value $FileName;

# start the AUT, its help file and get the window
Start-Process $testNames.AppName -PassThru | Get-UIAWindow -Seconds 120 | `
 Get-UIAMenuItem -Name Help | Invoke-UIAMenuItemClick | `
 Get-UIAMenuItem -Name 'Help*Topic*' | INvoke-UIAMenuItemClick;
Get-UIAWindow -Name $testNames.HelpTitle -Seconds 120;

function Invoke-TreeNodeExpand
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element
 )
 [void]($element | Invoke-UIAControlClick -DoubleClick -PassThru:$false);
}

function Invoke-TreeNodeCollapse
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element
 )
 [void]($element | Invoke-UIAControlClick -DoubleClick -PassThru:$false);
}
function Invoke-TreeNodeShowRightPane
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element
 )
 [void]($element | Invoke-UIAControlClick -PassThru:$false);
}

function Invoke-TreeNodeScrollTo
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element
 )
 [void]($element | Invoke-UIATreeItemScrollItem);
}

function Invoke-TreeNodeChildrenProcess
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element,
 [string]$NodeHierarchy
 )

 # children of the node or top-level nodes
 $children = $element | Get-UIAControlChildren -ControlType TreeItem;

if ($children -ne $null -and $children -is [Object[]] -and $children.Count -gt 0) {

# we store the previous node in a variable, so that
 # we can return to it and collapse its chilren
 # after we walked through all of them
 [System.Windows.Automation.AutomationElement]$previousChild = $null;

foreach ($childNode in $children) {
 try {
 if ($previousChild -ne $null) {
 # collapse the previous node
 Invoke-TreeNodeShowRightPane $previousChild;
 Invoke-TreeNodeCollapse $previousChild;
 }
 $previousChild = $childNode;

# expand the current node
 Invoke-TreeNodeScrollTo $childNode;
 Invoke-TreeNodeExpand $childNode;
 Invoke-TreeNodeShowRightPane $childNode;

# print out the hierarchy
 [string]$fullHierarchy = "";
 if ($NodeHierarchy.Length -gt 0) {
 $fullHierarchy = $NodeHierarchy + " -> " + $childNode.Current.Name;
 } else {
 $fullHierarchy = $childNode.Current.Name;
 }
 Write-Host $fullHierarchy;

# go down the hierarchy
 Invoke-TreeNodeChildrenProcess $childNode $fullHierarchy;
 }
 catch {
 Write-Host $Error[0];
 break;
 }
 }
 }
}

# first time, the tree is given as the root node
$rootNode = Get-UIATree -Seconds 120;
Invoke-TreeNodeChildrenProcess $rootNode;

The script accepts three parameters, as required, and a typical script run looks like:

.\HelpWalker2.ps1 services.msc Services '*Microsoft*Management*'

You should administrative rights or run PowerShell as administrator, if you are trying this sample. Usually, for regular applications, end user’s rights are enough.

Here are more samples how to run the script:

.\HelpWalker2.ps1 compmgmt.msc 'Computer*Management' '*Disk*Management*'
.\HelpWalker2.ps1 dsa.msc '*Active*Directory*Users*' '*Microsoft*Management*'
.\HelpWalker2.ps1 certmgr.msc *Cert* *Micr*Manag*

Daily automation: how to test help files. Part 1. Walkthrough


Testing of help files is a rather monotony task. What should be tested in help files? Usually, the list is

  • ability to run the help file itself
  • how the help file reacts on pressing F1 everywhere in the application UI
  • help pages hierarchy and navigation
  • help page are working, some txt are represented
  • hyperlinks work, inside the help as well as outside
  • the content of the pages (we can check only help topics and keywords, the rest, i.e. articles’ body, should be read by humans)

Today we’ll learn how to walk all the nodes in the help file.

Task: create a script that is a universal tool for navigating inside help files.

Requirements: the script should accept parameters as follows: file name of the application under test (AUT), the title of the AUT, the title of the help file.

Solution: below is the script that walks through all nodes except the cases the list is tool long to be shown in the tree (the API functions that are used can’t work in the invisible area):

param(
 [string]$FileName,
 [string]$AppTitle,
 [string]$HelpTitle
 )
Set-StrictMode -Version Latest
cls;

ipmo [path]\UIAutomation\UIAutomation.dll;
# set a small delay between nodes
# because the refresh of each page should take time
[UIAutomation.Preferences]::OnSuccessDelay = 100;

# create our enum object
[PSObject]$testNames = New-Object PSObject;
$testNames | `
 Add-Member -MemberType NoteProperty -Name AppTitle -Value $AppTitle -PassThru | `
 Add-Member -MemberType NoteProperty -Name HelpTitle -Value $HelpTitle -PassThru | `
 Add-Member -MemberType NoteProperty -Name AppName -Value $FileName;

# start the AUT, its help file and get the window
Start-Process $testNames.AppName -PassThru | Get-UIAWindow -Seconds 120 | `
 Get-UIAMenuItem -Name Help | Invoke-UIAMenuItemClick | `
 Get-UIAMenuItem -Name 'Help*Topic*' | INvoke-UIAMenuItemClick;
Get-UIAWindow -Name $testNames.HelpTitle -Seconds 120;

function Invoke-TreeNodeExpand
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element
 )
 [void]($element | Invoke-UIAControlClick -DoubleClick -PassThru:$false);
}

function Invoke-TreeNodeCollapse
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element
 )
 [void]($element | Invoke-UIAControlClick -DoubleClick -PassThru:$false);
}
function Invoke-TreeNodeShowRightPane
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element
 )
 [void]($element | Invoke-UIAControlClick -PassThru:$false);
}

function Invoke-TreeNodeChildrenProcess
{
 param(
 [ValidateNotNull()]
 [System.Windows.Automation.AutomationElement]$element,
 [string]$NodeHierarchy
 )

 # children of the node or top-level nodes
 $children = $element | Get-UIAControlChildren -ControlType TreeItem;

if ($children -ne $null -and $children -is [Object[]] -and $children.Count -gt 0) {

# we store the previous node in a variable, so that
 # we can return to it and collapse its chilren
 # after we walked through all of them
 [System.Windows.Automation.AutomationElement]$previousChild = $null;

foreach ($childNode in $children) {
 try {
 if ($previousChild -ne $null) {
 # collapse the previous node
 Invoke-TreeNodeShowRightPane $previousChild;
 Invoke-TreeNodeCollapse $previousChild;
 }
 $previousChild = $childNode;

# expand the current node
 Invoke-TreeNodeExpand $childNode;
 Invoke-TreeNodeShowRightPane $childNode;

# print out the hierarchy
 [string]$fullHierarchy = "";
 if ($NodeHierarchy.Length -gt 0) {
 $fullHierarchy = $NodeHierarchy + " -> " + $childNode.Current.Name;
 } else {
 $fullHierarchy = $childNode.Current.Name;
 }
 Write-Host $fullHierarchy;

# go down the hierarchy
 Invoke-TreeNodeChildrenProcess $childNode $fullHierarchy;
 }
 catch {
 Write-Host $Error[0];
 break;
 }
 }
 }
}

# first time, the tree is given as the root node
$rootNode = Get-UIATree -Seconds 120;
Invoke-TreeNodeChildrenProcess $rootNode;

The script accepts three parameters, as required, and a typical script run looks like:

.\HelpWalker.ps1 services.msc Services '*Microsoft*Management*'

You should administrative rights or run PowerShell as administrator, if you are trying this sample. Usually, for regular applications, end user’s rights are enough.

Here are more samples how to run the script:

.\HelpWalker.ps1 compmgmt.msc 'Computer*Management' '*Disk*Management*'
.\HelpWalker.ps1 dsa.msc '*Active*Directory*Users*' '*Microsoft*Management*'

Daily automation: crawling here and there


Sometimes, queries are not the best way to navigate along the Automation tree. Why? Get-UIA[ControlType] cmdlets return only one control. The Search-UIAControl cmdlet returns all controls that match, but it needs previously to run around all the Automation tree that may be too long in certain applications.

What if your only need is to get a few controls situated at the same level of the Automation tree? My choice is to get one and navigate to the next sibling. Theoretically, the control that a Get- cmdlet returned is the first sibling, i.e. navigating to the previous sibling is not demanded at the same extent as to the next sibling. Though, no one guarantees that the control you’ve been given is the first child of its parent.

Thus, several cmdlets are here to help you turning left or right when necessary.

Task: demonstrate how to navigate along the Automation tree.

Requirements: figure out which cmdlets are helpful regarding navigation.

Solution: the first example shows the mistake almost everyone makes. “It should be here, under this, why your cmdlets don’t work?” I hear similar questions regularly. Don’t be confused with your results: the control of your interest might be not here. Where? Anywhere? No, just one or more levels below the hierarchy. Let’s run the following code (all the pieces of code are based on the assumption that the UIAutomation module is loaded, of course):

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAControlChildren | %{ Write-Host $_.Current.ControlType.ProgrammaticName $_.Current.Name $_.Current.AutomationId; }

My Calculator returns three controls. Haven’t you been expecting that the Get-UIAControlChildren cmdlet would return all the buttons numbered from 0 till 9? Nay, they are level or levels below. Now, we’ll get all the descendants:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAControlDescendants | %{ Write-Host $_.Current.ControlType.ProgrammaticName $_.Current.Name $_.Current.AutomationId; }

This code returns tens and tens of controls. I even calculated to announce that this time it returned 73 controls:

(Start-Process calc -PassThru | Get-UIAWindow | Get-UIAControlDescendants).Count

The Search-UIAControl returns 75 objects (possibly, objects with empty name and automation id are being calculated in various ways), but somewhat slower: the cmdlet walks the Automation tree what requires much more process-to-process calls.

(Start-Process calc -PassThru | Get-UIAWindow | Search-UIAControl -Name *).Count

So where are the buttons? Just refine the search at first:

(Start-Process calc -PassThru | Get-UIAWindow | Get-UIAControlDescendants -ControlType Button).Count

Calculator in the Scientific mode returned 53 buttons, both buttons with numbers and signs and control buttons like ‘Minimize the window’.
Okay, let’s repeat the question: where our buttons are? Which control might be their parent? The main window? A pane under the main window?

(Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAcontrolParent).Current.ControlType.ProgrammaticName

Right, a pane. The full list of ancestors for this button is provided by the Get-UIAControlAncestors cmdlet:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAControlAncestors | %{ Write-Host $_.Current.ControlType.ProgrammaticName $_.Current.Name $_.Current.AutomationId; }

The main window contains a pane, it in turn contains another pane, which button are placed on.
It’s time to navigate horizontally:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAControlNextSibling

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAControlNextSibling| Get-UIAControlNextSibling

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAControlNextSibling| Get-UIAControlPreviousSibling

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAControlPreviousSibling

The first line of code returns the button 0, the second – MR, the third – (any doubts?) 1, the fourth – 4.

Eventually, we are going to know which of buttons is the first. To achieve this goal, we’ll get a button, get its parent, and get the first child:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAControlParent | Get-UIAControlFirstChild

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Get-UIAControlParent | Get-UIAControlLastChild

The first button is MC, the last (don’t you think that the Get-UIAControlLastChild is the less usable cmdlet if even me avoiding to use it?) – ‘ten in the X degree’.

After the navigating crash course has been conpleted, you are able to sail to wherever your controls are!

Daily automation: collecting access keys and accelerators keys


Working with an application under test using the keyboard is not a thing that the majority of us loves. What to speak, Microsoft guys would rebel against such tests. Although I’m also not a big fan of keyboard imitation, the post brought me to an idea to collect keyboard short cuts into a list.

For example, you need to have the full list of short cuts for further consideration, test planning, etc. Maybe, you are worrying about how to test localization to many languages and such a dump would be valuable.

Task: use UIAutomation to collect all the available on the current screen of the AUT access keys and accelerator keys.

Requirements: to form a tab-separated list of controls and their keys.

Solution: below is an example that can collect two levels of the menu items (the main menu and one level deeper). It works not bad, but in the last test, mspaint, it gets in the endless loop.

The whole script kill the WordPress engine (only the sourcecode area:)), so that I divided it into parts. The whole script will in the samples within the next version, 0.7.3, today later or tomorrow.

Set-StrictMode -Version Latest;
cls
ipmo [path]\UIAutomation.dll;
function Out-ElementDetail

{
 param(
 [System.Windows.Automation.AutomationElement]$element,
 [int]$level,
 [string]$parentAccessKey
 )

[string]$accessKey = $element.Current.AccessKey;
 if ($accessKey.Length -eq 0) {
 $accessKey = "None";
 } else {
 if ($parentAccessKey.Length -gt 0) {
 $accessKey = `
 $parentAccessKey + "=>" + $accessKey;
 }
 }
 Write-Host "$($level)`t" `
 "$($element.Current.ControlType.ProgrammaticName)`t" `
 "$($element.Current.Name)`t" `
 "$($element.Current.AutomationId)`t" `
 "$($element.Current.AcceleratorKey)`t" `
 "$($accessKey)";
 try {
 $global:dict.Add($accessKey, $element.Current.Name);
 }
 catch {
 Write-Host "Error: $($element.Current.Name)`t$($accessKey)";
 }
}
function Enum-Children
{
 param(
 [System.Windows.Automation.AutomationElement]$windowElement,
 [int]$level
 )

try {
 $apppid = $windowElement.Current.ProcessId;
 $elements = $null;
 if ($level -eq 0) {
 Out-ElementDetail $windowElement 0;
 try {
 $null = $windowElement | Invoke-UIAMenuItemClick;
 $elements = `
 Get-UIAWindow -ProcessId $apppid | `
 Get-UIAControlDescendants -ControlType MenuItem,SplitButton,Custom,ListItem;
 }
 catch {
 $elements = $windowElement | Invoke-UIAMenuItemExpand | Get-UIAControlDescendants -ControlType MenuItem,SplitButton,Custom; #,ListItem;
 }
 }
 if ($elements -ne $null -and $elements.Count -gt 0) {
 foreach ($element in $elements) {
 Out-ElementDetail $element ($level + 1) ($windowElement.Current.AccessKey);
 [void]($element | Move-UIACursor -X 5 -Y 5);
 try {
 Enum-Children $element ($level + 1);
 }
 catch {}
 }
 }
 if ($level -eq 0) {
 try{
 $null = $windowElement | Invoke-UIAMenuItemClick;
 }
 catch {
 $null = $windowElement | Invoke-UIAMenuItemCollapse;
 }
 }
 }
 catch {}
}
function Report-AccessKeys
{
 param(
 [string]$startName,
 [string]$stopName
 )

 if ($stopName.Length -eq 0) {
 $stopName = $startName;
 }

 [UIAutomation.Preferences]::OnSuccessDelay = 300;
 Write-Host "Access Key report for $($startName)";
 Write-Host "Level`tControlType`tName`tAutomationId`tAcceleratorKey`tAccessKey";
 [System.Collections.Generic.Dictionary``2[System.String,System.String]]$global:dict = `
 New-Object "System.Collections.Generic.Dictionary``2[System.String,System.String]";
 $topLevelMenuItems = Start-Process $startName -PassThru | `
 Get-UIAWindow | `
 Get-UIAControlDescendants -ControlType ToolBar,MenuBar | `
 Get-UIAControlDescendants -ControlType MenuItem,SplitButton,Custom,ListItem;

 foreach ($element in $topLevelMenuItems) {
 Enum-Children $element 0;
 }

 Stop-Process -Name $stopName;
}

Report-AccessKeys services.msc mmc;
Report-AccessKeys compmgmt.msc mmc;
Report-AccessKeys devmgmt.msc mmc;
Report-AccessKeys calc;
Report-AccessKeys notepad;
Report-AccessKeys mspaint;

The sample script crawls around controls and writes all the collected to the screen and in a dictionary (one dictionary per a function call).

Homework: fix the script. Script never finishes up mspaint with control types selected to work with (less types selected allow the script to finish, but the output is too poor). Also, it needs support of deeper levels of the menu (have you seen vSphere Client 5.0?).

Daily automation: eliminating the fragility of tests


Why do test fail? It’s the question every automated tester investigated into. Today we’ll discuss unexpected changes in the software under tests. This topic is hardly relevant to developers or even to testers in projects where no inexplicable changes allowed (have you seen any?).

When a new build is baked, and all nobody-knows-what changes are baked in, your tests might not find something vital and omit a great amount of the product functionality or stop completely.

One of solutions we accepted is to enable the search using wildcards. To our surprise, the wildcard search within a not great number of controls works with the same speed as the exact search. Wildcard search within a great number of controls is slower than exact search, possibly the latter uses caching or some hidden indices that we can’t use. There is a place for further investigation. In case of the fruitless search, both searches use almost the same time, the time the timeout told.

Task: use UIAutomation to get a control by a fragment of its name.

Requirements: compare times that needed for exact-match search and wildcard search.

Solution: below is the script that runs a process, gets its window, gets a control by exact match or using wildcard and reports the time used (part of the samples package) :

Set-StrictMode -Version Latest;
ipmo [path]\UIAutomation.dll;
[UIAutomation.Preferences]::OnSuccessDelay = 0;

# regular search
[UIAutomation.Preferences]::DisableExactSearch = $false
Write-host "exact matching (one of few controls of the MenuItem type):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAMenuItem -Name File}).TotalSeconds
Stop-Process -Name mmc;

# search with wildcards
[UIAutomation.Preferences]::DisableExactSearch = $true
Write-host "wildcard matching (one of few controls of the MenuItem type):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAMenuItem -Name Fil*}).TotalSeconds
Stop-Process -Name mmc;

# regular search
[UIAutomation.Preferences]::DisableExactSearch = $false
Write-host "exact matching (one of a heap of controls of the Edit):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAEdit -Name BranchCache}).TotalSeconds
Stop-Process -Name mmc;

# search with wildcards
[UIAutomation.Preferences]::DisableExactSearch = $true
Write-host "wildcard matching (one of a heap of controls of the Edit):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAEdit -Name Branch*}).TotalSeconds
Stop-Process -Name mmc;

# regular search
[UIAutomation.Preferences]::DisableExactSearch = $false
Write-host "exact matching (one of few controls of the MenuItem type):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAMenuItem -Name File}).TotalSeconds
Stop-Process -Name mmc;

# search with wildcards
[UIAutomation.Preferences]::DisableExactSearch = $true
Write-host "wildcard matching (one of few controls of the MenuItem type):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAMenuItem -Name *il?}).TotalSeconds
Stop-Process -Name mmc;

# regular search
[UIAutomation.Preferences]::DisableExactSearch = $false
Write-host "exact matching (one of a heap of controls of the Edit):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAEdit -Name Workstation}).TotalSeconds
Stop-Process -Name mmc;

# search with wildcards
[UIAutomation.Preferences]::DisableExactSearch = $true
Write-host "wildcard matching (one of a heap of controls of the Edit):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAEdit -Name ?orksta*i*n*}).TotalSeconds
Stop-Process -Name mmc;

# regular search
[UIAutomation.Preferences]::DisableExactSearch = $false
Write-host "exact matching (one of few controls of the MenuItem type - it takes the full time timeout is set to):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAMenuItem -Name nothing}).TotalSeconds
Stop-Process -Name mmc;

# search with wildcards
[UIAutomation.Preferences]::DisableExactSearch = $true
Write-host "wildcard matching (one of few controls of the MenuItem type - it takes the full time timeout is set to):";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAMenuItem -Name not?ing}).TotalSeconds
Stop-Process -Name mmc;

# regular search
[UIAutomation.Preferences]::DisableExactSearch = $false
Write-host "exact matching:";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAEdit -Name nothing}).TotalSeconds
Stop-Process -Name mmc;

# search with wildcards
[UIAutomation.Preferences]::DisableExactSearch = $true
Write-host "wildcard matching:";
(Measure-Command {Start-Process services.msc -PassThru | Get-UIAWindow | Get-UIAEdit -Name ?othing}).TotalSeconds
Stop-Process -Name mmc;

As can be seen, the search among controls that are not huge in number is so fast as exact matching. However, when it works among a significant number of control of the type chosen, search is slowing down. Why? Possibly, there caching is needed. No answer at the moment. the third part of the test script clearly shows that in an unhappy case both types of search fail at the same speed, after timeout expires.

Thus, for small applications or separate parts of a big one, there is the reason to use wildcard wherever it’s possible. Just to eliminate surprises your developers might easily involve you in.

Daily automation: exercising mspaint. Part 1


MSPaint within Windows 7 is a fun toy. Multi-level system of menu (command-tabs and drop-downs), Quick Access Toolbar, Zoom are the things that do mspaint quite similar to the Big Brother and sample for all forever, Microsoft Office. Well, let’s get accustomed with these controls.

Task: use UIAutomation to work with cutting-edge controls, for this goal explain how to use the search cmdlet with application’s menus.

Requirements: perform actions with a picture by means of menu items.

Solution: at first, start the application (don’t I need offer a bit more help? :)). The first example is how to completely renew a picture, i.e. create a new white sheet.:

Set-StrictMode -Version Latest;
ipmo [path]\UIAutomation.dll;
# create a new picture
Get-UIAWindow -pn mspaint | Get-UIACustom -Name 'Application menu' | Invoke-UIACustomClick | Get-UIAMenuItem -Name 'New' | Invoke-UIAMenuItemClick;
try{
 Get-UIAWindow -Name 'Paint' -Seconds 3 | Get-UIAButton -Name "Don`'t Save" | Invoke-UIAButtonClick;
} catch {
 Write-Host "the previous picture was as clean as snow";
}

Here a question can be raised: ‘what should we do if UIAutomationSpy obstinately gives us the code to access the Paste button that is beneath the list of menu items we are working with?’ Okay, there is a fault. The spy may suggest using the control underneath the mouse pointer on its own. Two controls are under the cursor, and the poor application may don’t know which of them we are interested in. Who is impeding us from using the search cmdlet? Below is the way how we can investigate into what the menu list is:

Set-StrictMode -Version Latest;
ipmo [path]\UIAutomation.dll;

(Get-UIAWindow -pn mspaint | Get-UIACustom -Name'Application menu' | Invoke-UIACustomClick | Search-UIAControl -Name 'New').Current;
%d bloggers like this: