Test run: UI Automation using Windows PowerShell

Despite the relatively short time available, Windows Powershelltm has become one of my favorite tools. I recently discovered that Windows PowerShell has all the features needed to create a small library that you can use to write Ultra lightweight UI Automation code.

In this month's column, I'll explain how to create a small, custom Windows PowerShell cmdlet collection to perform Windows®ui automation tasks. This includes obtaining the handles to applications and controls, manipulating controls, and checking application state. In this discussion, I will assume that you have a basic understanding of Windows PowerShell and call Win32®api functions on the microsoft®.net Framework p/invoke mechanism that uses the C # language. However, even if you're just starting to get in touch with this, a little bit of energy will help you understand this column.

Using Windows Powershell

For me, the easiest way to explain how to use Windows PowerShell to accomplish the essentials of Ultra lightweight UI automation is to use a screenshot, as shown in Figure 1. The first few lines of output in the shell only indicate that I am using Windows PowerShell. The next few lines indicate that you are registering my custom cmdlet, which is done by a custom startup script that runs whenever a new instance of the Windows PowerShell shell is started. (My startup script also sets the current working directory to C:\UIautomationWithPowerShell.) In this case, I've written and registered eight custom cmdlet to implement Ultra Lightweight UI Automation: Get-window, Get-control, Get-controlbyindex, Send-chars, Send-click, Get-listbox, Send-menu and Get-textbox.

Figure 1 Implementing UI automation using Windows PowerShell

Then, I issue the following command to display the names of all items in the current directory that start with the letter "T":

Copy Code

PS c:\uiautomationwithpowershell> Get-childitem t* | Select-object Name | Format-table-auto

In Figure 1, the output tells me that I have a directory named Theapptotest and a file named Testscenario.ps1. This file is my Windows PowerShell test script.

The Get-childitem command is one of approximately 130 built-in Windows PowerShell cmdlet. Many of these cmdlet also have aliases. For example, the Get-childitem cmdlet has several aliases-it can be "dir" (for people who are very familiar with the old Cmd.exe command shell and. bat files), "LS" (for engineers who are accustomed to UNIX environments), and "GCI" (a simple and convenient abbreviation in the command line).

My command routes Get-childitem output to the Select-object cmdlet, and I use the latter to filter the results to only the file and directory name attributes. I then used the-auto switch to channel the results to the Format-table cmdlet to produce a compact display. Of course, I could have just typed "Get-childitem" (or one of its aliases) without any pipeline transfer to accept all the default parameters for the command.

I can enter commands at the command line. \testscenario.ps1 to invoke my test script. Note that unlike most scripting languages, in Windows PowerShell, even if the script is in the current working directory, you need to use a relative path (as I did) or a full path to specify the path to the script. This is for security reasons. In addition, Windows PowerShell does not allow script execution by default, so if you want to run a script, you must explicitly start execution. You can check the current script execution policy by entering the command "Get-executionpolicy" and modify the policy by entering "Set-executionpolicy" with the parameter "remotesigned" or "unrestricted".

Once set, the execution policy on a specific system is still valid for all new instances of the Windows PowerShell shell and user sessions. When I start a new shell, the fact that my startup script (just a plain Windows PowerShell script) can actually execute shows that my current execution policy allows scripting to execute.