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]

Microcode: Cleaning up DVR with Get-RecordedTV

JamesBrundage — Mon, 21 Jul 2008 03:51:01 GMT

The first simple way we can approach cleaning up DVR is by making the assertion that shows you don't want as much you won't record as often. Suppose you record a movie once, or a game, or the pilot of a really bad TV show. After a month or so it's still on your hard drive, taking up space but for some reason avoiding the Windows Media Center's cleanup bots.

Now that we've got a fairly mature Get-RecordedTV, we can use it to delete a certain number of files from your collection until we reach a desired amount of freed space.

function Remove-DVRBySeries($cleanupSize = 1gb, $episodeCount = 1)
{
    $shows = @()
    # Pipe the results of Get-RecordedTV so that we can see progress
    $perc = 0

    Get-RecordedTV | Foreach-Object {
        $perc+=5
        if ($perc -gt 100) { $perc = 0 }
        Write-Progress "Getting DVR Metadata" "$($_.Series) - $($_.Episode) - $($_.Channel)" -perc $perc
        $shows+=$_
    }
    $showsbySeries = $shows | Group-Object Series
    $allSeries = $showsBySeries |
      Where-Object { $_.Count -le $episodeCount} |
      Sort-Object Count
    foreach ($series in $allSeries)
    {
        foreach ($e in $series.Group) {
            $response =Read-Host "Delete $($e.Series) - $($e.Episode) (Yes/No)"
            if ($response -ilike "*Yes*") {
                if ($e.File) {
                    Write-Progress "Deleting $($e.Series) - $($e.Episode)" `
                       "$($e.Size / 1mb) megabytes saved - $(($cleanupSize - $e.Size)/1mb) remaining"
                    Remove-Item $e.File
                    $cleanupSize-=$e.Size
                } else {
                    Write-Error "$($e.Series) - $($e.Episode) File Not Found"
                }
            } else {
                Write-Progress "Skipping show by user request" "$($e.Series) - $($e.Episode)"
            }
            if ($cleanupSize -le 0) { return }
        }
    }
}

This script will remove shows with one or fewer episodes until it has saved 1gb of space. If you want to make it save more, use the cleanupSize parameter. If you want it to check series with more episodes, use the -episodeCount parameter. It will ask to make sure you want to delete each show, and will stop once it has saved you enough space.

The script above uses a lot of simple PowerShell benefits. Let's take a closer look at each:

CleanupSize uses 1gb as its default. In PowerShell, you can use gb,mb,and kb as numbers, e.g. 1gb, 10mb, or 640kb
By piping Get-RecordedTV to ForEach-Object, I am able to store the results of Get-RecordedTV as they come in, instead of waiting for all of them to be completed, I can use Write-Progress to display each show as it comes in. Since I don't know how long it will take, I can just wrap the progress bar around whenever I get to 100%.
Group-Object will group all of the shows by the value of the series property
Sort-Object is used to sort the results of Group-Object by the number of items in each group (in our case, the number of recorded episodes of a series)
Write-Progress is used again to update the user as files are deleted or skipped
Read-Host displays a prompt and asks for user input
-ilike is a case insentive like, so $response -ilike will match "Yes", "yeS', or "Yes Sir", sadly, the logic will also catch "Yes, I mean No!"
Write-Error politely informs me that a file cannot be deleted, but does not stop execution of the script (this the important difference between Write-Error and throw)

That's it. We've brought one train of thought to an end. With this script, I was able to quickly and easily cleanup almost 40gb of shows that I wasn't watching. I hope it helps you clean up your hard drive, and I hope that explaining how to get here has increased your understanding of PowerShell scripting and problem solving.

Hope this helps,

James

Media And Microcode : Group-Object

Microcode: Scripting Tricks : Exploring WPF Routed Events with PowerShell

Microcode: Cleaning up DVR with Get-RecordedTV