Why Invoke-UIAControlClick -RightClick waits for mouse move?

Jun 25, 2012 at 11:13 AM

Set-StrictMode -Version Latest;
ipmo d:\DDN_docs\scripts\powershell\auto\UIAutomation.0.7.11.NET35\UIAutomation.dll 
ipmo d:\DDN_docs\scripts\powershell\auto\UIAutomation.0.7.11.NET35\TMX.dll 

#[UIAutomation.Mode]::Profile = [UIAutomation.Modes]::Presentation;
[UIAutomation.Mode]::Profile = [UIAutomation.Modes]::Normal;

Start-Process "compmgmt.msc" -PassThru | Get-UIAWindow; 

Get-UIATreeItem -Name 'Shared Folders' | `
    Invoke-UIAMenuItemExpand | `
        Get-UIATreeItem -Name 'Shares' | `
            Invoke-UIAMenuItemExpand;
$SharedItems = Get-UIADataGrid -Class 'SysListView32' | `
    Get-UIAControlDescendants -ControlType DataItem;
#Listing shares                     
foreach ($Item in $SharedItems) {
    Get-UIADataGrid -Class 'SysListView32' | `
        Get-UIADataItem -Name $($Item.Current.Name) | `
            Invoke-UIAControlClick -RightClick;
    "Right button pressed..." | Write-Host    
    break
}

Coordinator
Jun 25, 2012 at 12:28 PM

Hi, technically, it waits.

But there is a problem: a menu grown from the main menu or a context menu is also a window. Cmdlets do their best, but there is a practical observation: set [UIAutomation.Preferences]::OnSuccessDelay between 100 and 200. Something like dificulty to get a window (menu) by nothing (it doesn't have name of appropriate automaitonid).

I dodn't investigate into it (there always was a bunch of other things to investigate into), just an observation.

 

If it slow down all your test suite, set it for a piece of code.

(The version 0.7.12, possibly, introduces a good work with cache requests, I hope, and for applications with a lot of controls it promises to accelerate queries.)

Another thing, that is still in development is profiles. This means that such settings as OnSucessDelay will be set on a window or a container level (for example, for Pane). This will mean that slowing down caused by OnSuccessDelay=200 will be minimized.

Coordinator
Jun 25, 2012 at 3:07 PM

Oops! Sorry, JUSTASM, you have found a bug! :) I changed PostMessage to SendMessage in a method that is under Invoke-UIAControlClick cmdlet (and Invoke-UIAControlContextMenu as well).

I put PostMessage in place and your code works now. (My first thought was that a menu (i.e., a window that is a menu) is not painted when the code goes further. But you were right, mouse movement helped here as it 'pushed' the queue of messages that SendMessage was awaiting, as I think).

I'd like to suggest a couple changes to your code, if you's allow:

Variant 1:

foreach ($Item in $SharedItems) {
	Write-Host $Item.Current.Name;
    if (Get-UIADataGrid -Class 'SysListView32' | `
        Get-UIADataItem -Name $($Item.Current.Name) | `
            Invoke-UIAControlClick -RightClick -PassThru:$false) {
		"Right button pressed..." | Write-Host
	} else {
		"Right button failed..." | Write-Host
    }
    #break
}

Invoke- cmlets are able to return the AutomationObject they have been invoking pattern on as well as $true/$false for confitions like if. This sample should better response to what happens in the application.

The result is a logical sum of boolean results of the first PostMesssage (WM_xxBUTTONDOWN) and the second (WM_xxBUTTONUP).

Variant 2:

there is a special cmdlet for context menu that does the same (right click upon the geometrical center of a control).

foreach ($Item in $SharedItems) {
	Write-Host $Item.Current.Name;
    Get-UIADataGrid -Class 'SysListView32' | `
        Get-UIADataItem -Name $($Item.Current.Name) | `
            Invoke-UIAControlContextMenu
	"Right button pressed..." | Write-Host
    #break
}

both samples have been tested with 

[UIAutomation.Preferences]::OnSuccessDelay = 0;
(the same the Normal mode sets)

Jun 25, 2012 at 4:57 PM

OK, I use menus instead of mouse, and hope changes are committed in next build. You're doing great tool, thanks!