Where's the documentation?!

Apr 10, 2013 at 9:24 PM
I may not be the smartest guy in the room... but I'm not the dumbest. The documentation tab is completely void of anything. The examples don't really explain HOW to use it... just leads you by the nose on a couple of novel examples.

I started out very simply and it just isn't working. Opened notepad manually.
Select-Window -ProcessName "notepad" | Set-WindowActive | Send-Click -Button Right
The notepad window comes to the foreground but it does not right click. If it did right click I would get a menu box that would pop up.

I tried :
Select-Window -ProcessName "notepad" | Set-WindowActive | Send-Click -Button Left
Again it comes to the foreground but does not left click. If it did then the text I had highlighted from before would become un-highlighted as it clicked somewhere else.

Tried giving it a position thinking it wasn't anywhere in the window.
Select-Window -ProcessName "notepad" | Set-WindowActive | Send-Click -Left 800-Top 425 -Button Left
My desktop resolution is 1600x900 so it should be somewhere near the center which would be in the middle of my text document. Same behavior. I tried throwing in some start-sleeps and that didn't seem to make a difference.

Send-Keys seems to work
Select-Window -ProcessName "notepad" | Set-WindowActive | Send-Keys "derp"
It replaces what I had highlighted with derp which is exactly what i expected.

All I'm trying to do is simply send a left click, or hold left click for a duration of time, on an active window. It seems really simple but I don't get why it's not working.

Please advise or point me to some real documentation I can refer to.

Apr 11, 2013 at 3:43 AM
Yeah, sorry ... I've been playing with the UIAutomation script version of this and don't want to write documentation for this version because the new one is so different.

First off: I HIGHLY recommend avoiding clicks for UI Automation. They're unreliable because they have to have coordinates. Some windows won't respond to a click at 0,0 so you have to specify coordinates just to get them to work at all.

The problem you're having has to do with which element you're targeting and the exact coordinates being clicked. Send-Click targets the specific window/control that has been selected, and defaults to the 0, 0 coordinates, so your click is basically hitting the window border where nothing happens when you click or double-click.

The following works:
$edit = Select-Window notepad | Select-Control Edit 
$edit | Send-Keys "This is a test of the clickity-click system"
$edit | Send-Click -DoubleClick -top 10 -Left 10
The click selects the first word. It works because the click is going to the Edit control, and is offset at 10, 10 from the top left corner of the window. If you don't offset, the click goes to the border of the edit control, which still doesn't do anything. My guess is that in your example, 800, 425 is too far and going right off the window, but probably wouldn't work without targeting the edit control anyway.

But again, I wouldn't use clicks if I can avoid it. Send the keystrokes or move-window, etc when you can.

I am currently working on a Module Packaging system for PoshCode.org, but when that's finished, I will prioritize getting the next version of the UI Automation script version of WASP
Apr 14, 2013 at 4:55 PM
Edited Apr 14, 2013 at 4:59 PM
Send-Keys or Send-Click are both fine for what I want to do; so I'll try Send-Keys as you advise.

Again it works fine with Notepad but I don't really need to manipulate Notepad. I have game window that I want to send a key to.
Import-Module .\WASP.dll

Select-Window PS2 | Set-WindowActive

$PS2_Client = Select-Window PS2 | Set-WindowActive
That all seems to work fine there. Module imports, I can select the window and bring it to the foreground with Set-WindowActive.
Now lets try to send it some keys.

I bound the L key in the game to a simple function. If I interactively hit the L key on my keyboard it fires the main gun. However if I try this command... does nothing.
$PS2_Client = Select-Window PS2| Set-WindowActive

$PS2_Client | Send-Keys "LLLL"

The game window comes to the foreground .... and it's like stuck.... Click the mouse manually and it snaps back and operates interactively but it doesn't shoot the main gun.
Apr 14, 2013 at 7:12 PM
You may need to select a child control and send keystrokes to that.
Apr 14, 2013 at 8:00 PM
I feel like I'm missing a huge, fundamental, part of how this all works.

For example:
Select-Control - pick controls (children) of a specific window, by class and/or name and/or index (with wildcard support)

What are the classes?
How do I know one of them is Select-Control Edit other than someone telling me that is one of them?
How do I know which classes are available to a given program window object?
How do I figure out which child control to interface with?

Get-Help gives me some info but not ALL the info I need. Doesn't even mention "edit" or any other classes or how to even call a class:
PS C:\Temp\WASP> get-help Select-Control


    Select-Control [[-Index] <Int32>] -Window <WindowHandle> [-Title <String>] [-Recurse] [-Verbose] [-Debug] [-ErrorAc
    tion <ActionPreference>] [-WarningAction <ActionPreference>] [-ErrorVariable <String>] [-WarningVariable <String>]
    [-OutVariable <String>] [-OutBuffer <Int32>]
    Select-Control [-Class] <String> [[-Title] <String>] [[-Index] <Int32>] -Window <WindowHandle> [-Recurse] [-Verbose
    ] [-Debug] [-ErrorAction <ActionPreference>] [-WarningAction <ActionPreference>] [-ErrorVariable <String>] [-Warnin
    gVariable <String>] [-OutVariable <String>] [-OutBuffer <Int32>]
Apr 14, 2013 at 8:25 PM
The help is woefully lacking because the cmdlets are compiled (not script), I need to write MAML help files (which is still a pain in PowerShell) rather than just comment-based help. Anyway, the fact is, there's no way to know the answer to that.

Classes are created by programmers. There's a certain subset of them which are common ( "Edit" for instance), but there's an infinite number of possibilities (that's why there's not an enum tab-complete list). Same goes for Window handles, of course -- except worse: those are relatively random numbers generated by the system.

There's no way for me to know what classes are available in your app, that's why when you pipe a window (or a control) to Select-Control, it shows you all the immediate child items, by default. Normally, you just keep adding another | Select-Control ... until you find something that looks right.

The best way, perhaps, is to get out Spy++ or something like it and use it to CLICK on the control you want to interact with and find it's class...

Commercial tools come with recorders that will track each click and set it all up for you. There's actually another PowerShell UIAutomation project on CodePlex which claims to be able to do that (I haven't tried it).