WPF in PowerShell: PowerBoots 0.2

I’ve finally given over trying to improve PowerBoots for this iteration of development, and in between setting up the ScriptingGames.PoshCode site and releasing the PoshCode software on the main PoshCode.org site (it’s coming, I promise), I decided to take a few minutes and release this lates PowerBoots, and it’s a ground-breaking release, if I do say so myself!

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)

Similar Posts:

• PowerBoots (Next Generation UI) WPF for PowerShell slides
• Format-PoshTable – A Video
• Rich formatting for PowerShell help
• Creating WPF UIs for PowerShell with PowerBoots and Visual Studio WPF Designer
• What Scope Am I In?