Media And Microcode : Sort-Object

Microcode: Scripting RSS Feeds with PowerShell and Microsoft.FeedsManager

JamesBrundage — Tue, 11 Nov 2008 04:34:53 GMT

PowerShell's an amazing glue language. It can help you bring code from all corners of the earth into one environment, and then you can custom the code to be more to your liking. While the last several entries of my blog have spent time looking at what we can glue together with .NET, this one shows you how you can bring COM into the mix.

Internet Explorer has an RSS feed manager which you can script in .NET. While the command line might not be the ideal spot to read your blogs, it's possible to make a much nicer front end by scripting WPF & PowerShell, and having a quick and easy API to get at your RSS feeds makes building applications that use RSS feeds as a way to synchronize information between multiple machines.

The object that makes this all work is Microsoft.FeedsManager, and the cmdlet that makes working with it possible is New-Object. By default, New-Object will create a new .NET object from the classes that are currently loaded by .NET (for more on this, see my previous posts about Get-Type and Get-Assembly). While .NET is a fairly easy world to explore, COM is considerably more tricky.

Luckily, COM objects are the main backbone of VBScript. This is an important point for VBScripters trying to learn PowerShell: while the world of .NET may be new and exotic, and Cmdlets might be cool, you don't have to drop your VBScript knowledge at the door. While some of a VBScript (e.g. strings) will require new learning in PowerShell, the vast majority of it doesn't.

Microsoft.FeedsManager is one of these examples. I found out about this object by looking at the source code for the RSS reader vista sidebar gadget, and, once I knew its name, I knew how to get at it in PowerShell. Even though I was looking at javascript, I knew that there was a scriptable COM object there to help me out, and I knew how to bring it into PowerShell.

To create a Microsoft.FeedsMananger, simply use this one liner:

New-Object -comObject Microsoft.FeedsManager

Since the root folder looks promising, let's explore that:

(New-Object -comObject Microsoft.FeedsManager).RootFolder

While I can just save this into a variable and script it like I were still in VBScript land (e.g. $feeds = New-Object -comObject Microsoft.FeedsManager, $feeds.RootFolder), I far prefer the parlance of PowerShell, so I'll make a quick Get-Feed function to explore feeds more easily. I'll accept a wildcard for the name or title of the feed, and, since the feeds can have an arbitrary number of subfolders, I'll add a -recurse parameter. In order to make -recurse work elegantly, I'll use a short recursive script and I'll add a $folder parameter, which can be null and will be assumed to be the root folder. Finally, since I'll often want to read the items more than the feed, I'll add a switch parameter to extract the articles.

function Get-Feed($feed = "*", $folder, [switch]$recurse, [switch]$articles) {
    if (! $folder) {
        $feedsManager = New-Object -ComObject Microsoft.FeedsManager
        $folder = $feedsManager.RootFolder
    }
    $folder.Feeds |
        Where-Object {
            ($_.Title -like "$feed") -or ($_.Name -like "$feed")
        } | Foreach-Object {
            if ($articles) { $_.Items } else { $_ }
        }
    if ($recurse) {
        $folder.Subfolders | Foreach-Object {
            Get-Feed $feed $_ -recurse -articles:$articles
        }
    }
}

Once I've defined Get-Feed, I can use it to search my feeds through PowerShell. This one liner will get my all my feeds, sort them by name, and display just the Name and URL:

Get-Feed -recurse | Sort-Object Name | Select-Object Name, URL

To see all of the feed items sort them by when they were published, and display the post title, the blog title, and the publish date, you can use this pipeline:

Get-Feed -articles -recurse |
Sort-Object PubDate -descending |
Select-Object Title, @{Name='Blog'; Expression={$_.Parent.Title }}, PubDate

I promise that we can do much more with RSS and PowerShell, but hopefully this post will get you started down the path of using the FeedsManager from PowerShell.

Hope this helps,

James Brundage [MSFT]

Module Name	Scripts
RSS	Get-Feed

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