Media And Microcode : WPF

Write-Progress & WPK

JamesBrundage — Mon, 28 Dec 2009 21:10:43 GMT

A nifty trick that you can do in WPK is create a WPF progress bar to show the Write-Progress output from a PowerShell script. I was reminded that people actually wanted to do this when I ran across a question on StackOverflow, and posted this answer.

In case you don’t want to follow the link, here’s a quick script to show progress from a background runspace in WPK. The top half set ups a bunch of data bindings that will bind to whatever DataContext is found, and the second half of the script is a small sample of Write-Progress output.

New-Grid -Columns 2 {            
    New-TextBlock -Margin 10 -TextWrapping Wrap -ZIndex 1 -HorizontalAlignment Left -FontWeight Bold -FontSize 12 -DataBinding @{            
        "Text" = "LastProgress.Activity"            
    }            
    New-TextBlock -Margin 10 -ZIndex 1 -TextWrapping Wrap -Column 1 -VerticalAlignment Bottom -HorizontalAlignment Right -FontStyle Italic -FontSize 12 -DataBinding @{            
        "Text" = "LastProgress.StatusDescription"            
    }            
    New-ProgressBar -ColumnSpan 2 -MinHeight 250 -Name ProgressPercent -DataBinding @{            
        "Value" = "LastProgress.PercentComplete"            
    }            
} -DataContext {            
    Get-PowerShellDataSource -Script {             
        foreach ($n in 1..100) {            
            Write-Progress "MajorProgress" "MinorProgress" -PercentComplete $n            
            Start-Sleep -Milliseconds 250            
        }            
    }            
} -AsJob

Hope this Helps

James Brundage [MSFT]

Microcode: A Quick Trick to turn regular XML into Xaml

JamesBrundage — Thu, 22 Jan 2009 13:07:36 GMT

MSDN has tons of examples about XAML. Nearly everything in WPF has an example in XAML, but not all of these XAML examples actually reference the namespace that is required for this Xaml to be loadable by WPF. It's still valid XML, just not valid XAML.

Here's a quick example of what I mean. I just copied and pasted this chunk from the MSDN topic on LinearGradientBrush:

<Rectangle Width="200" Height="100">
<Rectangle.Fill>
    <LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
      <GradientStop Color="Yellow" Offset="0.0" />
      <GradientStop Color="Red" Offset="0.25" />
      <GradientStop Color="Blue" Offset="0.75" />
      <GradientStop Color="LimeGreen" Offset="1.0" />
    </LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>

Now if I try to simply load that up as XAML, XamlReader barfs

$x =[xml]'
<Rectangle Width="200" Height="100">
<Rectangle.Fill>
    <LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
      <GradientStop Color="Yellow" Offset="0.0" />
      <GradientStop Color="Red" Offset="0.25" />
      <GradientStop Color="Blue" Offset="0.75" />
      <GradientStop Color="LimeGreen" Offset="1.0" />
    </LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>
'
[Windows.Markup.XamlReader]::Parse($x.OuterXml)

Exception calling "Parse" with "1" argument(s): "'' XML namespace prefix does not map to a namespace URI, so cannot resolve property 'Width'. Line '1' Position '79'."
At line:14 char:35
+ [Windows.Markup.XamlReader]::Parse <<<< ($x.OuterXml)
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException

Obviously, that's not ideal. Luckily, with CTP3, there's a cmdlet called Select-Xml, which will allow me to query a document with xPath, regardless of namespaces.

This means that I can check to see if the fist element has a reference to the WPF namespace, and add it if it's not there.

$t = $x |
    Select-Xml //* |
    Select-Object -First 1 |
    Foreach-Object {
        if (-not $_.Node.xmlns) {
            $_.Node.SetAttribute("xmlns", 'http://schemas.microsoft.com/winfx/2006/xaml/presentation')
        }
        $_.Node.OuterXml
    }

I'll stop and explain this pipeline a little. $x is the XML, I pipe it into Select-Xml, with the xPath parameter of //*. //* roughly translates to any node. I pick out the first node (with Select-Object -first 1) and then I check to see if the Node contains an xmlns attribute. If it doesn't, I add it. Either way, I emit the first node's OuterXml, which basically means I emit the entire XML chunk as text. That's what $t is when I am done.

Then I use this chunk to display it:

$w = New-Object Windows.Window
$w.Content = [Windows.Markup.XamlReader]::Parse($t)
$w.SizeToContent = "WidthAndHeight"
$w.ShowDialog()

Now I have the MSDN sample working, regardless of if it had an xmlns attribute in the first place.

Hope this Helps,

James Brundage [MSFT]

Microcode: Scripting Tricks : Exploring WPF Routed Events with PowerShell

JamesBrundage — Mon, 20 Oct 2008 03:12:00 GMT

Both WPF and PowerShell are both full of great little touches. One of WPF's nice touches is Routed Events. Routed Events allow you to capture events raised by child controls or parent controls. This can be incredibly useful, because it allows you write less code (which I believe is generally good) by re-using handlers.

A good example of why you might want to do this is wanting to have more than one button in a user interface that updates a database. What each button might do may be different, but they all to connect to a database. This means you could write either write three longer (and less portable) methods that connect to the database and perform an operation, or three shorter ( and more portable ) methods that just perform the operation on a database and one operation that connects to the database. By having each of the buttons go through a routed event on a container, you can write one short routing handler that connects to the database, looks at where the message came from, and performs the operation.

WPF comes with an amazing number of controls, and a pretty nice selection of Routed Events. The WPF team was event nice enough to have a manager for these routed events, which means that we can explore them dynamically using PowerShell.

The event manager is available in the class System.Windows.EventManager. Let's start exploring it with PowerShell. To do this, make sure you've loaded the WPF assembly into PowerShell by using the line [Reflection.Assembly]::LoadWithPartialName("PresentationCore"). We can omit the System namespace when referring to a type in PowerShell, so we can call it [Windows.EventManager] from now on. We can use Get-Member -static to see what this class can do.

[Windows.EventManager] | Get-Member -static

It has the following methods:

Equals (every .NET object has this static member)
GetRoutedEvents()
GetRoutedEventsForOwner(Type ownerType)
ReferenceEquals (every .NET object has this static member)
RegisterClassHandler (Type classType, RoutedEvent routedEvent, Delegate handler)
RegisterClassHandler (Type classType, RoutedEvent routedEvent, Delegate handler, Boolean handledEventsToo)
RegisterRoutedEvent(String name, RoutingStrategy routingStrategy, Type handlerType, Type ownerType)

Since I'm just exploring, GetRoutedEvents() is the method I'm interested in.

I can see every routed event with the simple PowerShell one-liner:

[Windows.EventManager]::GetRoutedEvents()

Of course we can pipe that to Get-Member in order to see what we've got for every Routed Event:

[Windows.EventManager]::GetRoutedEvents() | Get-Member

It's more interesting to me to figure out what events I can bubble up to the parent controls. Since each RoutedEvent has a RoutingStrategy property, I can write this as a simple filter using Where-Object:

[Windows.EventManager]::GetRoutedEvents() | Where-Object { $_.RoutingStrategy -eq "Bubble"} | Sort-Object Name

Since each RoutedEvent also has a HandlerType property, I can also see what types of different handlers exist by using

[Windows.EventManager]::GetRoutedEvents() | Group-Object HandlerType | Sort-Object Count -descending

Finally, I can use the EventManager to help guess about what types of controls could fit the bill for whatever I need to do. The next one liner gives me all of the routed events that work with Drag and Drop

[Windows.EventManager]::GetRoutedEvents() | Where-Object {$_.Name -like "*Drag*" -or $_.Name -like "*Drop*" }

Associating these events with a class needs to use some tricks of reflection. In the sample below, I'll look for all drag and drop handlers within PresentationBase (where the EventManager and some base components live) and PresentationFramework (where most of the built-in WPF controls reside):

$handlers = [Windows.EventManager]::GetRoutedEvents() |
    Where-Object {
        $_.Name -like "*Drag*" -or $_.Name -like "*Drop*"
    }
$assemblies = [Windows.EventManager].Assembly,
    [Windows.Window].Assembly

$assemblies | Foreach-Object {
    $_.GetTypes() | Where-Object {
        foreach ($handler in $handlers) {
            if ($_.GetEvent($handler.Name)) {
                return $true
            }
        }
    }
}

The script above takes a bit of explaining.

I store the Drag and Drop handlers into a variable, and store the assemblies I wanted to search in another variable (to search all of my currently loaded types for these handlers, I'd use just assign $assemblies to [AppDomain]::CurrentDomain.GetAssemblies()). Then I go through each assembly, retrieve the types, and pipe them into Where-Object, which will determine if they meet my criteria. I go through each class and each handler that met my criteria, and use the GetEvent method (which is defined on any .NET type definition) to determine if the event is present. If the event is present, I return $true, which makes the Where-Object output the type. If the event's not present, then code will go onto the next handler and the next type.

These are just a few examples of the ways you can use PowerShell to explore WPF routed events. The techniques used in this post can be used on to explore just about any .NET type. Exploring .NET through reflection is a great way to save time looking things up, and the pathway to using existing .NET code to solve a problem rather than reinventing the wheel.

Hope this helps,

James Brundage [MSFT]