WPF From PowerShell – Select-Grid

After looking over the scripts I’ve pasted in the last few days it struck me that all of them load the UI from XAML — and for the most part, you can do pretty much whatever you need to do in WPF in pure PowerShell if you want to.

To demonstrate this, I wrote a simple Out-Grid script. But then I got carried away, and wrote the script I’ve shown in this screenshot. The resulting script not only illustrates how to code WPF in PowerShell without XAML, it also illustrates one of the few areas where you’re much better off loading from XAML than writing the plain code — and that’s a DataTemplate. It is possible to write them in code, but believe it or not, some of their features are accessible only from XAML.

I’ve updated both the script and the screenshot to correct a bug I noticed last night after I posted this … so if you tried this and got a lot more columns than you had bargained for … here is the Select-Grid script again. I updated it again just now to switch my Set-PsDebug statement for a Set-StrictMode statement, after reading Jeffrey Snover’s post about strict mode best practices.

I’m not going to paste the whole script in-line, but I thought I’d paste some of it here so that I could give a little explanation of what’s happening, in case you need a little help figuring it out…

Using modules …

Some of you may know that normally in a script like this we would put the “utility” functions inside the BEGIN block so-as to encapsulate them from your main runspace, and may be wondering why I didn’t in this case. It’s because the new CTP2 of PowerShell has this concept called a “module” ... which is somewhat like a script snapin — basically it allows you to have functions in the script which don’t end up in the main runspace, but which are still available to the other functions (or cmdlets, in this case) in the script.

I will write a separate post about how PowerShell Modules work, and what you can do with them … it’s too complicated to get into here. Suffice it to say that all I had to do to the script is add a line at the bottom: Export-ModuleMember Select-Grid and rename it to Select-Grid.psm1 and put it in a specific location: Documents\WindowsPowerShell\Packages\Select-Grid\Select-Grid.psm1 — but of course, I couldn’t resist cleaning it up a bit as I was writing about it (if you grabbed it before v3.4, you should grab it again — look in the comment at the top).

Having done that, all you have to do is run Add-Module Select-Grid instead of dot-sourcing it, and then run it as before (see the screenshot).

Let’s talk about code bay-bee …

There’s a few things I wanted to point out in the module’s code, so lets get to that. The first thing is that the main code is in a cmdlet, rather than a function — mostly because the cmdlet automatically handles both command arguments and pipeline arguments and allows me to handle them both the same way. Since I want to handle all of the input at once, my BEGIN and PROCESS blocks are basically empty, serving only to collect the inputs.

One caveat I will point out: The CTP has a problem where it strips the ETS attributes from things when you specify the type. So if you write a cmdlet with a parameter types like [System.IO.FileSystemInfo], and then add data to them with Add-Member, that data won’t show up in the script cmdlet. Hopefully this will be considered an important bug and will be fixed in the next CTP/Beta. The workaround in the meantime is to just use [PSObject] when you want to get the ETS attributes.

So, lets review the important bits of this …

This constructs the window, and the only things I’ll point out here is that I used SizeToContent so that the window would automatically adjust it’s size, and I put the ListView and GridView directly into their containers, instead of assigning them to variables first. It might help you to have a $grid or a $list variable to work with in the rest of the code (eg: instead of $window.Content.View = new...GridView, you’d be doing $list.View = $grid), but since this is PowerShell and not C#, I don’t end up having to manually cast things to use their specific properties, so this actually keeps my code cleaner. In C# this would be a mess, because the View property is only a property of a ListView type, so you would have to cast the $Window.Content to a ListView in order to use that property, and then … well, lets just say the last line of that code would end up something like this (assuming you were using the namespaces and didn’t have to type them out):

The next interesting feature of this code (at least, in my opinion) is the Get-PropertyTypes function — I won’t elaborate much here, but the purpose of this code is to get a hash of the property names and types when the user specifies a list of properties to show. The main reason I did this that I was having problems sorting columns with missing values, so I go through the values and add a NoteProperty with an appropriate default (for which I need to know the variable’s type).

We then construct columns for each property we want to bind to. This could be drastically simplified if we didn’t need the sorting, but since we do, it looks like this:

That block only has one thing worth mentioning that might not be clear from the comments: to avoid double-sorting the data, we have to Clear() the SortDescriptions before we add a new one (otherwise it sorts when we add, and then sorts again when we remove the old SortDescription). Since we need to know the direction that the current sort is in, I refactored it into a module-level variable, and wrote a New-SortDescription function which creates the SortDescription based on that … allowing me to clear without first capturing the current sort direction, and then add the SortDescription straight to the GridView. Script modules rock — they are essentially a “class” semantic for PowerShell, with private member variables and everything.

The last thing I should write about is the CellTemplate magic. If you pass a Graph parameter to the cmdlet, it puts a custom CellTemplate on each column you name. If you specified the Properties parameter, you have to be careful to only specify column names which you also included there, and in general, they have to be numeric columns in order for this to work.

There’s really only three lines of code here (not counting the Xaml), so lets review them. First we add a “PropertyPercent” NoteProperty to each output object for each “Property” that we want to graph, and populate it with the appropriate value. Then, we find the appropriate column in the GridView that we’ve already set up — and remove it’s DisplayMemberBinding. If we don’t remove the binding, the CellTemplate has no effect.

Finally, we add the CellTemplate. The magic is that the cell template has a colored Rectangle behind a TextBlock, and uses a ScaleTransform — bound to the “PropertyPercent” NoteProperty we created earlier — to scale the width of the Rectangle. I can’t stress enough that this is just one of hundreds of possible visualizations you could use, so let me give you a few ideas, and then you should go find a friend that’s an artist or a designer and get them to spend some time playing with Expression Blend …

1. You could have a DataTransform that converted numbers to colors, and bind the TextBlock’s BackgroundBrush to that so each cell is simply colored differently (eg: to color cells from red to blue based on a temperature value).
2. You could databind the FontSize of a TextBlock based on a numeric value in a non-displayed property, so you could show words with relative size (like a “Tag Cloud”).

1. You could databind the Angle property of the RotateTransform on a pair of lines or shapes to create an analog clock to display times

So many possibilities …

Similar Posts:

• Disabling Events in ShowUI
• How to: Invoke PowerShell and use the results from C#?
• ShowUI: Handling Events and Producing Output
• ShowUI: the tutorial walkthrough
• WPF Window “Native” Behavior: Metro Window