• Windows PowerShell
• Beginner

Always committed to starting the New Year right, I’m heading to Scottsdale, Arizona on Tuesday, January 5 at 5:30 PM to meet with the newly revived Arizona PowerShell User Group. We’ll meet at the Microsoft Store in Scottsdale Fashion Square. (I will not be distracted by the Surface Pro 4 on display. I will not…)

I’ll be there to lead an interactive hands-on lab in which participants build a basic PowerShell GUI application – essentially, a graphic user interface for a PowerShell script. When you press a button, it runs part of the script. When you type text in a textbox, the script can get the text and use it, such as for parameter values.

GUI apps like this one are not a replacement for Windows PowerShell scripts, but they’re a great strategy for delegated administration, which is a fancy way to describe a scenario in which someone who doesn’t know PowerShell needs to run a script. It’s also great for creating dashboards of scripts and automating PowerShell features.

The hands-on lab is fun because everyone participates and learns from each other. And, it’s truly a learning experience, not just a listening fest, because everyone is building something. We hit the first-timer bugs and tackle them right there, so you don’t encounter them when you’re alone at work under deadline pressure.

Thinking in Events? Why?

This lab is about PowerShell scripts, graphic user interfaces, and apps, so why is it called “Thinking in Events?”

        A Windows PowerShell script for a GUI application consists of an unordered collection of event handlers.

Yes, you read that correctly. If it sounds strange to you, you’re not alone. This is not the Windows PowerShell you learned.

And, there’s more.

        The order in which the events handlers run is determined by the end-user.

If you work with end-users, you can now add “scary” to “strange.” PowerShell scripts for GUI applications do not run in the predetermined linear way that standard scripts run.

When you write a GUI application in an object-oriented language, like Windows PowerShell, the elements of the user interface — the background form, the textboxes, the buttons, and the labels — are objects, just like processes, services, strings, and AD users.

These objects have properties and methods (and we use them), but they also have a member type called an event. Events are triggered by end-user actions. When an event happens, the system looks for instructions to tell it how to respond to the event. These instructions are called event handlers and you can write them in Windows PowerShell. To associate an event with an event handler, you register the event.

For example, my GUI app has a Close button (a button labeled “Close.”) When you click the Close button, the Click event of the Close button happens or “is raised” and the system looks for an event handler for the Click event of the Close button. If you’ve written a script and registered it as the event handler for the Click event of the Close button, whenever the user clicks the Close button, the system runs your event handler script.

New way of thinking: Non-linear event scripting

It’s a bit odd. We’re building a graphic user interface front-end for a Windows PowerShell script. But, the most novel part is not the form, buttons, or text boxes — they’re just objects. Instead, the most novel part is the way you think about it.

A GUI application typically contains multiple event handlers. At a minimum, there are click events for all of the buttons, text-changed events for the text boxes, and a Load (startup) event for the application form. You might also have events for menus and icons, like the one that displays help.

So, while designing your events, you have to decide which part of the code goes in which event handler, also known as: “Where do I paste this code I found on Google?” Not your typical PowerShell script.

Also, when you write a standard Windows PowerShell script, you determine the order in which the statements in the script run. The script might include some functions, or some IF or SWITCH statements that create a branch, but the script author still determines the running order.

In GUI app development, regardless of the language or the technology you select, you have to thinking in terms of end-user-initiated events.

Because end-users can and will type in and click anything you give them, you need to use an entirely different strategy to assure that you have the information you require before you run a cmdlet in your script. Otherwise, your script will generate preventable errors.

Displaying Output and Errors

The worst thing about an error in a GUI application is that the user can’t see it unless you create a display for it. In fact, the user cannot see any output unless you create a display for it.

In a typical Windows PowerShell script, the errors and other output, including verbose, warning, and information messages, appear the console. The script author doesn’t need to think about it.

However, in a GUI application, there is no console. So, if you don’t create a display for output and errors, users don’t see them at all. You can imagine the consequences.

So, that’s why I call this PowerShell GUI lab “Thinking in Events.” You’ll write a PowerShell script, build a GUI app to run it, and then package your script and app in an executable file for distribution. But, the most intriguing part of the exercise is learning to think in a whole new way.

June Blender is a technology evangelist at SAPIEN Technologies, Inc. You can reach her at This email address is being protected from spambots. You need JavaScript enabled to view it. or follow her on Twitter at @juneb_get_help.

• Prev
• Next