This release of PowerBoots is the most exciting release software I’ve cranked out in awhile. It finally has almost all of the features that I have thought of so far (we’re still missing proper support for attached properties).

• You can create pretty much any WPF element, including ones I haven’t thought of adding yet (use Add-BootsFunction to add a new assembly or a single type).
• You can create graphical user interfaces from PowerShell 1.0 all the way to the latest PowerShell 2.0 CTP.
• You can create your WPF GUIs -Async in their own threads, or inline in PoshConsole, or as synchronous dialogs that return values when they close.
• You can capture screenshots of your UIs (eg: generate .jpg charts from Visifire). You can even do so without displaying them!
• You can take advantage of XAML Data Templates to generate graphical representations of any objects in the PowerShell pipeline.

• You can add to, or modify your running GUIs from the command line.

You can read the “and much much more” between the lines right?

Breaking Changes and New Features

The big new thing in this release is that I’ve added a compiled module (PoshWpf) which contains several cmdlets, and gives us some major new functionality in exchange for a break in the syntax. The syntax change is pretty simple, really, and the new threading functionality (and PowerShell 1.0 support for the cmdlets) is awesome (if I do say so myself) .

New-BootsWindow replaces Out-Boots

New-BootsWindow is a compiled cmdlet, and in addition to all of the features already present in the now deprecated Out-Boots, it features a few important new features. Incidentally, I’ve actually left the old Out-Boots function in the code, just in case, but I’ve renamed it to Out-BootsWindow, and changed the “Boots” alias to point at the new New-BootsWindow.

ScriptBlock Content

The biggest change to your scripts is going to be a change from piping objects into Out-Boots, to creating your objects in a scriptblock parameter to New-BootsWindow. This allows the script to create the UI elements entirely within the new thread. Since we’ve switched the “Boots” alias to point to New-BootsWindow, anything you used to write like this: ... | Boots you should now be able to write like this: Boots { ... } and get the same result. Additionally, to make the syntax of our little DSL just a little bit slicker, I now allow you to pass scriptblocks for just about everything (particularly for the main content parameters). An example that looked like this, before:

Can actually end up like this, now (and produce the same output):

The Async Parameter

If you specify -Async, the new popup window is spawned in a new thread, and all of it’s events etc. are handled on that separate thread. This is actually what happens anyway when you run New-BootsWindow from a host that’s not running in STA mode, but if you don’t specify -Async, we fake the synchronous result so that you can use Write-Output within a dialog to prompt and get a result “returned” from New-BootsWindow. The cool thing about -Async is that not only can you continue using your console, you can run additional windows, and you can even use the new Invoke-BootsWindow cmdlet to run scripts within that window’s thread so you can change the GUI content, etc.

The Passthru Parameter

The -Passthru parameter causes the New-BootsWindow to output the window object that it has created to the pipeline. It’s really only useful when you also specify the -Async parameter, since otherwise the window will be closed before you can use it. Furthermore, because it’s a UI element, you can’t really do very much directly on the Window object without the use of our other cmdlets

The BootsWindow Collection

When you create a New-BootsWindow, the PowerBoots module (or snapin, for v1 users) tracks the window for you, so you can get ahold of it again later to run scripts against it, take screenshots, close it, etc. To enable this we have three new cmdlets:

• Get-BootsWindow returns the windows, and supports filtering by title or index.
• Remove-BootsWindow will clear the list of windows that have already been closed, when called without parameters, or will close (and remove) windows that are still running if you pass a specific window, index, or window title.
• Invoke-BootsWindow lets you run scriptblocks in a specific window’s thread

• Export-BootsImage lets you take a screen capture of the contents of a window (or of a specific control)

Add and Remove Templates

There are three new cmdlets for managing XAML source files. Add, Remove, and Get BootsTemplate. These allow you to specify additional XAML files (beyond the default.xaml), and those templates are always automatically loaded into each new window, so you can specify styles, resources, data templates and even new WPF Templates (I’ll throw up an example using the ones from WPF Themes later this weekend).

Download and Source now hosted on CodePlex

Well, that’s enough for the highlights for now. I’ve included the first blush efforts of a ps1xml format and data types files (which get loaded automatically with the module on PowerShell 2, but not v1), and I haven’t yet written up the help files for the compiled cmdlets. Look for more help and examples and maybe even some cleaned up sample videos over the weekend. Please file any problems you have as bugs on Boots.CodePlex.com, where you can find the latest release.

I do want to point out that I’ve left the version number at 0.1 … I really want to add some explicit support for attached properties, and I’m sure I’ve missed a bug or two somewhere along the line lets consider this another solid beta release.

The problem was, half of the need we have for graphs is to throw them up on a web-server … so I needed a way to take the WPF window, and capture the controls and visuals as an image. Basically, render the WPF control to a bitmap image, instead of to the screen. To cut a long story short, I figured it out of course — why else would I be writing this? (get it here).

Out-BootsImage

So the new version of PowerBoots includes the Out-BootsImage function (aliased as BootsImage and “obi”), which basically is designed to take the filename of an image, and a boots visual element, and create a screenshot. It can generate bmp, gif, jpg, png, tiff, and even Microsoft’s new wdp format, or it can output to clipboard.

It’s late, so I’m not going to write any more about this … the bottom line is, if you have been looking for a (free) way to generate graphs and charts to image files in PowerShell, this will work for you: go grab Visifire, check out their gallery for inspiration, and start churning out graphs! Just for fun, here are the samples from the help documentation (except, this is the actual script I ran, including the upload code) with screen-shots …

Important note

When producing images of Visifire charts using this method, it is absolutely critical that you must specify -Animation $false because otherwise you will consistenly produce images of empty charts (since by default Visifire animates all of the bars onto the screen right after the SourceInitialized event that I use to capture the image). Oh, and if you need to remove the Visifire.com watermark, there is a -watermark $false parameter on the Chart element, which turns it off.

Now with tab completion

The biggest change in PowerBoots 0.0.4 is that tab-completion for parameters works in the shell.

Behind the scenes what has happened is that I’ve discovered that in the current CTP3 release of PowerShell 2, Dynamic Parameter sets are not handled correctly for aliases, and the Get-Command for aliases of functions doesn’t return the same set of parameters as it does on the function itself. The result is that Tab-Completion for dynamic parameters doesn’t work on aliases (neither the built-in tab completion, nor MoW’s PowerTab). I wrote up a bug against that, but I also found that I can work around it by creating hundreds of functions (all pointed at the same script-block), instead of hundreds of aliases (all pointed at the same function).

PowerBoots produces functions instead aliases

This means the PowerBoots commands show up by default when you run Get-Command. Incidentally, this means that the first time you run Get-Command after you Import-Module PowerBoots you incur a huge penalty (17 seconds on my machine) while Get-Command caches all the dynamic parameter information about the functions. NOTE: because of the DynamicParam bug, I’ve ditched aliases altogether for this particular project and am generating two functions for each element/type in PowerBoots: the full New-Namespace.Type version, and a “Type” alias when possible. Trust me when I say: “it’s worth it” ... with the backing scriptblock, there’s virtually no difference between the two approches in terms of resources (other than the aforementions hit on Get-Command).

Now with more controls

The second big change (and the one which I hope will have the biggest long-term impact) is that you can now import your own WPF control libraries into PowerBoots. This means that you can, for example, go get the open source Visifire charting library, extract their WPFVisifire.Charts library into your PowerShell folder, and use it like so:

The main thing required to add new types to PowerBoots is to call Add-BootsFunction and pass it a Type or an Assembly … however, in order to get the nice clean syntax, and pipeline support for the “content” property (without having to specify the parameter name), we have to know which properties should be the default. PowerBoots has special handling for ‘Content’, ‘Child’, ‘Children’, ‘Items’, ‘Blocks’ and ‘Inlines’ which are the properties used by the various content models of the built-in WPF controls. I also added ‘GradientStops’ to make it easier to work with the GradientBrushes. But Visifire (and other third-party controls) may not follow this very well, so in order to get the simple syntax for Visifire that you see here, I modified PowerBoots so that ‘DataPoints’ and ‘Series’ would be added as Content properties.

Now, I’ve added functions to allow you to Get, Add, or Remove from the collection of these default property names … so you can call Add-BootsContentProperty to add to the list of property names which should be treated as default properties. You can also list them, and remove from the list. You should use these features with care, because if you have two default properties on the same object, you’ll probably have problems. There’s no need to worry about adding duplicate names though, so if you want to write a PowerBoots-based module to, say, make charting easier … you could just require PowerBoots, and then call Add-BootsContentProperty and add the types you wanted functions for … and then add your customized functions.

Visifire … Slick Charting!

I’ve been meaning to write a whole post dedicated to Visifire and what it can do — even the screenshots you’re seeing here don’t really do it justice. It has very nice configureable mouse-over tooltips, all the chart elements are interactive, you can add hyperlinks to data points, or manually handle events like MouseEnter, and MouseDown/Up/Click with a simple scriptblock, and you can even add context menus, text input, etc. There’s a really good silverlight graph gallery on their site — pretty much anything you see there, you can do in Visifire — And now, you can do it all from PowerShell, easily. This is actually why I’ve been holding off writing about it, because their default syntax is a bit of a pain to work with, especially from PowerShell, with all the New-Object calls, over and over.

PowerBoots makes working with Visifire charts from PowerShell much easier, but you still have to specifically create the DataSeries and DataPoints, even if you don’t want to specify any parameters for them. If I keep using the Visifire stuff, I’ll eventually have to create a New-DataSeries function along the lines of Select-Object: taking a hashtable to define the values for the DataPoint, like ls | New-DataSeries @{YValue={$_.Length}; AxisXLabel={$_.Name}} or something. In the meantime, to create the graph on the right, you need to do something like this:

The Invoke-Http and Receive-Http commands here are courtesy of HttpRest, and in this case, the XPath I’m using returns the total number of hits on Google for each search term…

What sorts of graphs and charts do you need?

Obviously Visifire lets you create all sorts of charts. Everything from stock tracking, to computer uptimes, to file sizes … I’ve got a few examples here, but really I need a few more real-world ones.

How about a graph of your active directory structure?

We can show the number of users at each location (or in each group, or whatever) fairly easily from ActiveDirectory. The interesting thing about this task, however, is that it lends itself to piping the data, instead of getting the data inside. If you don’t like this syntax (it is a little harder to read, I think) you can always write the whole AD stuff inside a $(evaluation) block for the content (the -DataPoints parameter) of the DataSeries function.

Or perhaps a graph showing the relative age and size of the files in a directory …

Bubble charts are a bit more complicated, just because there’s more stuff to set. You should really have a look at the Visifire Documentation, because there are a metric boatload of options and parameters, and a lot of the parameters that are present on the DataPoint element are only used for certain charts (like ZValue, which is only for bubble charts).

In this example I also set the ToolTip text so you can see how to do it, and I store the DataSeries so that I can remove things from it later on… thought that would be a useful example

We handle clicks by writing the selected objects out (in this case, to the Remove-Item cmdlet), and then removing them from the graph so they can’t be selected again. If you run this script an play with it, you’ll notice that VisiFire charts automatically redraw when you remove an item, so if you click on the largest file(s), the rest of the files bubbles will grow…