Now I’ve dug an old clock of mine out of mothballs and updated it to run on ShowUI — I believe that I’ve never posted this script before, so I don’t feel bad at all doing so now, even though I actually wrote it last December (hey, look, I have a screenshot against my bright red Christmas wallpaper to prove it — totally random, I know). Anyway, here’s the deal: this post was supposed to be written 6 months ago, about building fun UI Widgets in PowerShell, but I never got to it, because we started working on the PowerBoots + WPK merger we call ShowUI. So here’s a fun little function for you:

That script is what I use to create little “gadget” style windows that are transparent, don’t show up on the taskbar, but are draggable, and have an automatic update based on a timer. Now, this is a very simple version of the gadgets, without using our PowerShell “DataSource” or any data binding at all. I intend to update this with more functionality one of these days, but this was enough to make my clock work. You can see that basically all it does is sets a bunch of parameters for the Window, including a SourceInitialized event handler, and all the stuff necessary to make it transparent and draggable.

Now let me post the New-TargetClock funtion, which depends on that function, and we’ll get to explaining it a bit down below. First, the screenshot, this is what it looks like (with a PowerShell window behind it, instead of that bright red wallpaper):

And then the actual function:

What do you think of that?

The clever part (which, believe me, took a LOT of experimenting), is that I’m creating a StrokeDashArray and animating the StrokeDashOffsetProperty in such a way that the “stroke” of the Ellipse (the circle of the clock) gets drawn slowly over time (very slowly, in the case of the hour “hand”). Now, as you can see, I’m still setting up the animations by hand (I just didn’t convert the code to use Start-Animation), and in the UpdateBlock, I actually reset the animations if they’re at zero. I can write more about this if people have questions, but it’s nearly 2:30am, so I’ll take questions tomorrow

However, I’m writing today because I went back this week to revisit that project because I wanted a “Metro” style Window — basically, something like the Zune client window.

As I was reviewing it, I discovered System.Windows.Interactivity class which came out of Expression Blend, and includes the functionality of my NativeBehaviors attached property with regards to allowing you create new behaviors for WPF elements … and of course, despite being newer, their system has much broader support than mine

So anyway … long story short: I’ve rewritten my behaviors on top of System.Windows.Interactivity.Behavior and written a MetroWindow behavior that makes my PowerBoots application look roughly like this:

I’m really pleased with the results, and while I was at it I finally fixed a weird glitch in the Snap-To behavior when using the Win+Left or Win+Right keys in Windows 7 to move the window docked from the left of one monitor to the right side of another (or vice versa), and of course this also includes the global hotkeys behavior, and my Quake-console behavior The code to make add the MetroWindow behavior along with the SnapTo would be just:

I’ll write this up a bit more later when I’m ready to release PoshConsole and the revised Quake behavior, for now you’ll have to be content with the screenshots, unless you want to grab source code.

WPK:

Command : $boxes = 1..100 | % { New-TextBox -Text Foo -FontFamily Consolas -On_GotFocus { $_ } }
Duration : 5.25153s

Current PowerBoots 0.2:

Command : $boxes = 1..100 | % { TextBox -Text Foo -FontFamily Consolas -On_GotFocus { $_ } }
Average : 9.40994s

You can see why I thought I should probably work on improving that. It was bad.

PowerBoots 0.3 yesterday:

Command : $boxes = 1..100 | % { TextBox -Text Foo -FontFamily Consolas -On_GotFocus { $_ } }
Duration : 7.43874s

PowerBoots 0.3 tonight:

Command : $boxes = 1..100 | % { TextBox -Text Foo -FontFamily Consolas -On_GotFocus { $_ } }
Duration : 0.34103s

Now, if you’re like me, you’re probably thinking I screwed up something and that TextBox isn’t actually getting created right …

Postscript: ran another test. A little more useful. I have 248 fonts on my system. I have an “Samples” script which shows them all:

Old PowerBoots:

Duration : 19.39894s

New PowerBoots:

Duration : 3.53100s

So crank up your Visual Studio Express Edition and make yourself some user interfaces!

Basically, you just create a WPF project in C# or VB.Net or whatever … I chose to name my project “XamlForBoots” — your project will start off with an empty MainWindow.xaml file which will look something like this:

After you drag a few more controls onto the form, and you’ve created a complete user interface, you should delete the x:Class attribute. You need to make sure you know the name of the controls you want to interact with, so you might end up with something like this (I used the property pane, which you can’t see in this shot, to name each textbox and the button):

At this point, we’re ready to drop into PowerShell and write some script. Now … there is one catch here. The first script I’m going to show you here is for PowerBoots 0.3 (which will be the first release candidate for a gold 1.0 release, and will be out soon™). However, I’ll post below some code to make it work on the current release, but it requires an external function.

So, in the next release, you can just do something like this:

The key thing you’re supposed to notice here is that the named controls in the XAML are automatically surfaced as variables in the event handlers, and all you have to do is write your logic and hook it up to the controls. We provide a Register-BootsEvent cmdlet which is like Register-ObjectEvent except that it executes the event handlers on the UI thread (so they can do things to the UI) instead of in a new runspace, but basically it’s like calling Add_Click. Of course, you can use Register-ObjectEvent if you just want to spin off PowerShell tasks that don’t read/write the UI.

Backwards compatibility

To get this to work in the current release, you need a function Export-NamedControl to create variables for each of those named controls as variables. Once you’ve defined that function, you can write code very much like I did before, but you have to call Export-NamedControl yourself, and you won’t have that Register-BootsEvent cmdlet. You don’t really need it for this anyway, so that’s not a big deal, at least in this case. Here’s the function. and the actual code to create the window. You can just paste this into a script file:

And in order to try my demo, you’re going to need that MainWindow.xaml file:

PowerShell 1.0 Compatibility

There are three huge changes in this release, actually. But the biggest one is that most of the functionality works in the released version of PowerShell 1.0! There are still a few glitches and bugs when it’s running in 1.0, but I’ve decided it’s past time I just release it and let you start using it! If you use it on 1.0, please let me know if you run into anything weird, or problems you can’t figure out workarounds for.

Cached Script Functions!

The second biggest change is that all of the functions are now cached. The first time it’s loaded, PowerBoots actually writes out a few hundred scripts files into a “Functions” subfolder, and from then on, they’re only loaded when they’re used — saving you a lot of time at startup, and a lot of memory. Additionally, when you load in additional controls, such as the Visifire WPF chart controls, those functions are cached permanently too, so you never even have to manually load the assembly again!

Dependency Properties

A few people have asked over the last few months about how to set attached properties and dependency properties in WPF from PowerShell, so in this release I’ve included full support for these in a way that will, I hope, simply work so well it will boggle your mind All you have to do to tell a control, for instance, to be in the 3rd column of a grid is to just pass Button "Click Me" -"Grid:Column" 2 … it’s THAT simple. In fact, for properties that have unique names, you don’t even have to specify the type, just the name, like -Row 3 to specify the grid row.

Regression and Backwards Compatibility

Of course, the downside of these changes is that some of the syntax has changed a little bit. All scripts and event handlers (ie: click handlers for WPF Buttons) are run from the dll module scope in PowerShell 2 (the global scope in PowerShell 1), which means that they can’t access “script” scope variables from your scripts (which ends up meaning you have to declare a lot of things global that you could leave in script scope before). Just to be clear on the quality of this release: once we have ironed out the minor problems we’re having with PowerShell 1.0 in a way that I’m comfortable with, I expect to push the version number up and release an 1.0 Release Candidate, barring any major issues.

In order to help with the transition, I’ve included a Samples.ps1 script which has 28 sample scripts in it (mostly from the original Tutorial Walk-through, which I will update soon). I’ve updated each of them to work with this release, in both PowerShell 1 and PowerShell 2 (which means they’re almost all written in PowerShell 1 syntax), so you can use them as good examples of how to get things done!

Please use the Discussions Forum and Issue Tracker on the CodePlex site to post any problems you have, and I’ll try to write up a few more posts describing changes and differences in the next couple of weeks.

Related articles by Zemanta

• PowerBoots: Loading XAML Windows in PowerShell 1.0 or 2.0 (huddledmasses.org)
• PowerBoots: PowerShell GUIs are now multi-threading (huddledmasses.org)
• PingMonitor: interactive WPF UIs from PowerShell (1.0 or 2.0) (huddledmasses.org)

An introduction to PowerBoots

Please excuse me if I start by just copying the basic ideas of the Shoes Tutorial, but I figured that since PowerBoots is inspired by Shoes, that was as good a place as any to start. PowerBoots (or just “Boots”) is a PowerShell 2.0 module with functions for writing Windows Presentation Framework (WPF) applications in the PowerShell scripting language. You should get the latest version of PowerBoots before continuing, and install it by putting the “PowerBoots” folder in one of your “Modules” folders (list them by typing $Env:PSMODULEPATH in PowerShell v2).

Don’t forget to start PowerShell.exe with the STA parameter (This is no longer required in PowerBoots 0.1).

Did I hear someone ask what is WPF? It was introduced as part of .Net 3.0 (and vastly improved in .Net 3.5), so you can expect to find it preinstalled on computers from Vista on, and of course you can download and install it on XP if it’s not already installed. The only thing you really need to know about WPF for the purposes of this tutorial is that it is the new GUI toolkit for .Net, and that it is container based — you put elements into other elements to control the layout, rather like HTML and Java Swing… you can pick up the rest as we go along.

A simple Boots program

I’ve recently changed this first example to pass a script block to the content instead of using parentheses, because although PowerBoots supports running in an MTA PowerShell host, the only UI-creation command that is MTA-safe is the New-BootsWindow command. All of the “new” functions must then be inside of a scriptblock which is passed to the New-BootsWindow cmdlet and executed on that STA thread. You can use parenthesis ( and ) as a container instead, but that requires the host to be in STA threading mode (run: PowerShell -STA) so the controls can be created:

This first example is a bit uglier than the Shoes syntax, so lets see if we can’t clean it up some. The -Content parameter is positional, so the first non-named argument you pass will be used for that. The same is true for the -Children parameter of panels, and in fact, each of the other similar parameters: Items, Blocks, and Inlines.

We have used a function New-BootsWindow which has an alias Boots. Boots takes all the same parameters as the Window function mentioned previously, but it uses slightly more useful defaults, and has a few other major benefits as well, the first of which is that it automatically “shows” the window, and the second is that it supports an -Async parameter which allows the window to come out in a new thread so that you can continue using PowerShell while the window remains alive and responsive. There is one catch: New-BootsWindow cannot take it’s content on the pipeline (the old function, now renamed “Out-BootsWindow” can take pipeline content, but is a script function, and requires -STA mode) — you have to specify it as a ScriptBlock. So now that we know this, we can rewrite our first example like this:

Just for the record, the simplest Boots program would just be a simple popup dialog to put some text in a Window, like: Boots { $msg } …

We can put controls in a stack

StackPanels are awesome. So are WrapPanels. Try that code with a WrapPanel instead of a StackPanel and see what the difference is. This brings up another point: those positional parameters we mentioned earlier: Content, Children, Items, Blocks, and Inlines, are also set to accept the value from the pipeline. Not only that, but they are intelligent about whether or not the content model accepts multiple items! So we can actually rewrite that script like this, and get the same results:

Now we’re really onto something! For most of the rest of these examples, I’m going to stick with the former syntax, because with the indenting and parenthesis, it’s much easier for you to follow, especially if you’re not already familiar with WPF. For instance, check out what this does:

Ok, lets see some formatting

To scoot the buttons out from the edge we can use margins or padding: margins go on the outside of containers, padding goes on the inside.

So you see, the pink background is on the StackPanel, which has a (white) margin around it. If you wanted the whole background of the window to be pink, you would need to set the background of the Window instead of the StackPanel.

Time for some artwork

In Boots, everything always starts out white, and you must position things based on the container. You can see that the Margin can be specified as a single value as in the previous example, or as separate values for Left, Top, Right, Bottom. Oddly, to satisfy PowerShell’s type-casting, you have to quote them so they’re a single comma-separated string, instead of four separate values.

Some more advanced drawing

We use a Canvas for this because it can contain multiple items which are all absolutely positioned. Unlike other containers, it doesn’t automatically expand to contain it’s children, so you typically have to set it’s size.

We also have to set the Stroke and Fill. These are the two colors that make up every object, if we don’t set them, they default to white. The StrokeThickness controls the line thickness. Notice that we positioned the Rectangle by using the Margin, and positioned the arrow, which we built using a Polygon, based purely on the x,y coordinates of the points. The available shapes are Ellipse, Line, Path, Polygon, Polyline, and Rectangle. You can, of course, make any shape you want to with the Polygon.

There are other more advanced shapes available in external libraries, and we can even do 3D, use gradient or image fills…

We can even get images straight off the web

Boots loads the image on a background thread, and caches it in memory, so the window will show up and be responsive while you’re waiting for the image, and because we’ve specified -Async, you can actually continue using PowerShell while the image loads. Note: it will load much faster the second time you run that script.

Typography

PowerBoots doesn’t try to create a full set of typography-specific top-level elements the way Shoes does, because we are based on WPF, which has a far more powerful typography system available than any we’ve ever used. So instead of having a bunch of named elements like banner, and title, and caption, and para and whatnot, we have controls based on how much text you want to put in them, and how much formatting you want to apply: Label is simplest, TextBlock supports limited text formattings, and FlowDocument supports full rich content. And of course, Hyperlink supports clicking

For the typography elements, the content model changes a bit. There are basically two types: Inline and Block elements. The TextBlock Content Model is similar to that of a FlowDocument, it is actually a type-restricted “Items” container. Instead of being able to have anything as content, it can only contain Inline flow content elements such as AnchoredBlock, Bold, Hyperlink, InlineUIContainer, Italic, LineBreak, Run, Span, and Underline, and it will create a run automatically if you just put a text string in it.

Note: If you want support for the full document model (which allows Paragraphs and Lists), you need to use a FlowDocumentReader, FlowDocumentPageViewer, RichTextBox, or a FlowDocumentScrollViewer ... there’s lots more information about those on msdn.

Events

If you were paying attention to that previous example, you’ll notice we just introduced event handling. Event handlers in PowerBoots are specified in much the same way that Properties are. Their parameter names always start with “On_” and they take a script block. The Hyperlink element in a WPF window doesn’t automatically open a browser (because you can use it to change “pages” in a WPF application), so to make simple web links work, you have to handle the “RequestNavigate” event as shown above.

In order to update your user interface when an event triggers, you’ll need to have a variable that points at the control(s) you want to affect. You get a $this variable for free which points at the object that caused the event (eg: the Hyperlink in our previous example), but otherwise you need to handle this yourself. You can do that one of two ways: you can set a variable the way you normally would, and then use the variable in the form, or you can specify the variable name using the -OutVariable parameter. Personally I prefer the latter, as it messes up the flow of code less, but it has the downside that the output variable is always an array, even when there’s only one item.

I’ve made these examples slightly more complicated than they had to be to demonstrate some best practices. When the Window is closed, the Out-Boots function returns the $BootsOutput variable — so if you want to output something from your gui, you need to set that variable. You can, of course, access global scope variables using the scope prefix $global:variableName, so you can set many different variables which you read later in your script. The catch is, sometimes the variables have to be explicitly set to script or even global scope in order to refer to the same variable in all of the event handlers…

However, if you want to have this block of code actually output something into the pipeline, you’ll always want to use the $BootsOutput variable. You can do that directly, the way the example above does, or you can simply use Write-Output! Inside the Out-Boots function, he Write-Output cmdlet just appends to the $BootsOutput variable … so it works pretty much exactly the way you would expect it to.

The first example outputs just the count of how many times you clicked. The second outputs a series of numbers from 1 to however many times you click. It’s your choice of how to work with it.

We can have fun with colors

Boots gives you access to all the capabilities of the Windows Presentation Framework, but in some cases that comes at a cost, because we haven’t simplified their composability. So we have RadialGradientBrush and LinearGradientBrush, but you have to specify the GradientStops etc …

We also have

So what does an InputBox look like?

Well, the simplest possible input box is just a TextBox, with the Width set (if you don’t set the Width, a TextBox will adjust to fit it’s contents, which can be really distracting). All you need to do is this:

Of course, the problem with that is that it pops up this rather confusing window, when what we really wanted was a prompt, and an “Ok” button, and some event handling to make the thing behave the way we expect it to. So lets try our first complicated form.

I’ll warn you ahead of time of one thing I’m going to do here. I’m using the “Border” element to apply a colored border to the StackPanel (because it doesn’t have it’s own border parameters), but then I’m also using the WindowStyle and AllowsTransparency properties to remove the normal window chrome, creating the bare little popup you see in the screenshot. I handle the mouse down event on the main window to allow the user to drag the window around by clicking anywhere on it (except in the TextBox or on the Button, of course). Now it looks slick, and —you know— it works!

Hopefully you can follow that, although it’s obviously over the top . We handle the KeyDown event on the TextBox (if the Key is the Return key), and we also handle the click on the Button. In both cases, we’ll write out the text that was entered, and use the special $BootsWindow variable to close the window. We also handle the Load event for the window, to make sure the focus is on the TextBox, so you can just start typing.

A final example

I’ve got quite a few more examples I want to show off in part two of this tutorial, but to get you thinking about ways to integrate this with your routine tasks, and give you some ideas of what you can do with what you know already, let me give you this example of browsing photos, with a visual indication of how big the image file is. Of course, the point is that you could be visualizing, you know … anything.

Notice that I had to manually handle the concept of a double click, because StackPanels don’t have a Click or DoubleClick event, just MouseDown and MouseUp. I could have stuck the stackpanel into something that does, but there’s really no need. Also, the [Diagnostics.Process]::Start is the equivalent of typing the name into the run dialog. I’m just executing the jpg, which makes it open in the default editor. It’s just a sample, after all.

End note

The current version of Boots does not add threading support, which means that when you run something through Boots, execution of your script stops until the window is closed. You can get around this somewhat in various different ways, but future releases will support running the WPF window in a separate thread, and even communicating to it … at the expense of a slightly different syntax. If you need that functionality, feel free to let me know … I could use some motivation.

I hope you’ve enjoyed this tour through PowerBoots, and will be able to start applying it for fun and profit.

Just for fun, I’m going to rehash an earlier post about updating windows to show how you can go about this using PowerBoots, and hopefully show that it’s a little easier (and a lot more async). Compare and contrast the code in this article with that one, just for fun.

This works with any version of PowerShell

Unlike the original article, most this code (except where explicitly mentioned) works on either PowerShell v2 with PowerBoots, or PowerShell 1.0 with PoshWPF, a snapin that is part of the PowerBoots module but is also released separately… Also, unlike those previous posts, this does not require you to be running PowerShell.exe with the -STA switch, since the New-BootsWindow cmdlet takes care of threading for us.

The simple splash screen

This is, of course, not a great example of why you would want to use XAML, since it reads virtually the same as it would if you wrote it in PowerBoots (if you were on PowerShell v2):

The big difference, of course, is that this is fully aync, so unlike the splash screen in the original post, we don’t have to do any tricks to get it to render, and we are able to add a MouseDown handler so you can drag the splash screen around while you wait for it to go away…

And now, for something completely different

Let’s skip over the very useful information I already wrote about the properties you can set on the “Window” object in WPF (all of which are parameters to New-BootsWindow, by the way) and cut straight to the second example … I’ve tweaked an old WPF sample I had and ported it to PowerShell, and now, adapted it for PoshWpf ... the xaml file is here and I’ll show you the code just as soon as you take a look at the screenshot (trust me, the code will make more sense if you’ve seen the output):

So basically, the UI is defined in a href=‘http://HuddledMasses.org/wpf-from-powershell-updating-windows/clock/’ rel=‘attachment wp-att-528’>that xaml file, and all we need to do in the script is update the time, update the CPU bar, and update the RAM bar…

Please notice the content block

PowerBoots passes the window object itself into the content scriptblock, and the content block must output the content you want in the window. Of course, if you’re loading a fully defined window in XAML, you don’t want to change the Window’s content, but you have to return something, so you should just return … the content that’s already in the window. Ie: $Args[0].Content

One other point, for those of you who are going to become XAML masters. In PowerBoots you can define just the styles and templates as resources in a separate XAML file which you can load with the Add-BootsTemplate, and then you can still create the UI in XAML or useing PowerBoots syntax. In my case, this XAML was edited using kaxaml (it could have been Expression Blend, or Visual Studio), and kaxaml doesn’t make it easy to separate out resource files, so I just left it all in one file:

So, meet Register-BootsEvent

If you’ve read the previous PowerBoots articles, you know that you can specify events as parameters to the PowerBoots functions, like -On_Click or -On_MouseLeftButtonDown, but in the case where you’re loading XAML, you can’t specify events in the XAML (WPF’s XamlReader won’t read XAML with events on it, or even with the Class specified, because you can’t use the associated code file anyway).

In any case, what I’m adding to the next version of PowerBoots/PoshWpf are two functions:

1. Find-BootsControl takes a boots window and the Name of a control, and will (try to) find the named control. Of course, for that to work, you need to know the name of the control (your best bet is to name it yourself, but in the next version I may also issue names for elements as they are created if you don’t specify the name).

1. Register-BootsEvent takes either a control, OR a boots window and control name, plus an event name and a ScriptBlock. If you pass the window and name, it calls Find-BootsControl to find the control; once it has a control, it registers the ScriptBlock as a handler for the specified event.

For now, both of these require that you’ve assigned a name to the control, but I’m working on setting things up so controls would be automatically named (based on their type, as with the old WinForms designer: like Button1, Button2, etc.), or allowing an XPath-like selection without named controls. In any case, this will work nicely for generating event handlers for WPF imported from XAML, and you can even specify the element directly (ie: if you don’t specify the -Name parameter, the event will be hooked on whatever element you pass in) so that last block of code can be written like this in the next release:

I’m still thinking about the best way for me to expose this in PowerBoots, because the problem is that attached properties can get attached several ways, and not just on direct children of an element. So I wanted to show you a way that you can do it for now so you can at least use the DockPanel effectively:

A better way …

Here’s what I’m thinking about for the next release of PowerBoots (you can take this and use it now, if you like it, but I’m really looking for, uhm … better ideas). Basically, I have written a function: Set-AttachedProperty, which takes an attached property and a value, and passes through the element on the pipeline. You may want to use this in conjunction with the module I published awhile back for creating type accelerators, because it lets you run a line like this:

Which will let you substitute [DockPanel] for [System.Windows.Controls.DockPanel] … and of course, you can use it for all the types you want to use attached properties from, and it’s a real lifesaver if you need to use a bunch of them. Of course, in this particular example, we really only need to use a single attached property, so it’s enough to define that property ahead of time:

Then you can use the Set-AttachedProperty function through an alias sap, and rewrite that huge block above like this:

Pretty slick, right? And it will even print out the list of values in the error message if you invoke it with an invalid value against an enum property like dock: sap $DockProperty "" … The problem I have with it is that you have to predefine your $DockProperty variable, and you can’t just define it against the root class. So I’m trying to find a way to tweak the dynamic property generation to make it so that the pipe into | sap $DockProperty Bottom can just be a parameter to the original element: -Dock Bottom … if I can’t find that, in the worst case scenario, I’ll just add an -AttachedProperties parameter with a hashtable of $DockProperty,“Bottom” or something … what do you think?

In any case, here’s the sap function, for now, and remember to use it as part of the pipeline:

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.