MSDN Magazine - December 2007 - (Page 95) UI Automation with Windows PowerShell DR. JAMES MCCAFFREY T hough it has only been around for a relatively short amount of time, Windows PowerShell™ is already one of my favorite tools. I recently discovered that Windows PowerShell has all the features you need for creating a tiny library that will enable you to write ultralightweight UI automation. In this month’s column, I will show you how to create a small collection of custom Windows PowerShell cmdlets that perform Windows® UI automation tasks. These include obtaining handles to applications and controls, manipulating controls, and check ing application state. In this discussion, I will assume you already have a basic familiarity with Windows PowerShell and with call ing Win32® API functions using the Microsoft® .NET Framework P/Invoke mechanism with the C# language. But even if these are new to you, you should still be able to follow this column with a little bit of effort. Using Windows PowerShell The easiest way for me to illustrate the key points of using Win dows PowerShell for ultralightweight UI automation is with a screenshot, as shown in Figure 1. The first couple of lines of output in the shell simply indicate that I’m using Win dows PowerShell. The next few lines then tell me that my custom cmdlets are being regis tered; this is done by a custom startup script that runs every time a new instance of the Win dows PowerShell shell is launched. (My startup script also sets the current working directo ry to C:\UIautomationWithPowerShell.) In this example, I’ve written and registered eight custom cmdlets for ultralightweight UI auto mation: getwindow, getcontrol, getcontrol ByIndex, sendchars, sendclick, getlistBox, sendmenu, and gettextBox. Next, I issue the following command to display the names of all items in the current directory that begin with the letter “t”: PS C:\UIautomationWithPowerShell> get-childitem t* | select-object Name | format-table -auto The getchilditem command is one of approximately 130 built in Windows PowerShell cmdlets. Many of these cmdlets also have aliases. The getchilditem cmdlet, for instance, has a few aliases—it can be given as “dir” (for those most familiar with the old cmd.exe command shell and .bat files), as “ls” (for those en In Windows PowerShell, gineers used to a UNIX you must explicitly enable environment), and “gci” (a simple abbreviation for execution if you want convenience at the com to run scripts. mand line). My command pipes the output of getchilditem to the selectobject cmdlet, which I use to filter the results down to just file and directory name properties. Then I pipe that result to the formattable cmdlet with an auto switch to produce a condensed display. Of course, I could have typed just “getchilditem” (or one of its aliases) without any pip ing to accept all the default arguments for the command. I can invoke my test script by entering the command .\testSce nario.ps1 on the command line. Unlike most scripting languages, In Figure 1, the output tells me that I have a di rectory named TheAppToTest and a file named testScenario.ps1. This file is my Windows Pow erShell test script. Figure 1 UI Automation with Windows PowerShell december2007 95
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.