Let’s say you had a form that collected a bunch of user input, and then had a button that would fire off some work. We’ll assume that you wanted to prevent people from firing off the work again before they know the results of the first time, so you’ll disable the button while you’re working. Something like this (leaving out the boring stuff about collecting the user’s input and displaying the results):

It’s pretty simple. In fact, I think there’s only three things worth pointing out:

1. There are variables for named controls.
2. If you want to make sure a control has time to update it’s display while you’re executing your event handler, call UpdateLayout().

1. You can disable and enable buttons.

Now, try doing the same thing with Windows Forms.

This was my first attempt:

Now, I bet you noticed that took a bit more code than the WPF version in ShowUI, but the thing about it is that I also had to manually specify the positions of the controls (and I had to set the size of the form to make that work). And after all that, it still doesn’t actually work, and it has a few ugly behaviors:

First of all, disabling the control doesn’t work, because Windows posts all click events as messages to the button’s message queue, and it doesn’t know that it should ignore them, because it only processes one at a time — when it’s done running the Click handler the first time, it notices there’s another event … and since it’s enabled, it processes it. If you click it five times while it’s disabled, you’re going to get the work done five more times… eventually.

On top of that, although the label updates without being told to, it didn’t push the button down the screen or resize the form, so eventually it overlaps the button, passes through the bottom of the form and disappears.

The next thing I tried was to actually unhook the event handler before I disable the button … but that had no effect either, because (as I wrote earlier) the button doesn’t actually ignore the clicks while it’s doing the work — it just queues them up for processing later.

Of course, I could do the work in a background job so that the button would return immediately, but that doesn’t meet the requirements I have for not queuing up extra work before the first work is done, and in fact, then I’d have extra work to do to create a time to check and see if the remote job was finished or not.

[New] Thanks to SAPIENDavid, I’ve realized the simple fix for the disabling problem, we just have to call DoEvents to empty the event queue before we re-enable the button.

Here’s what did work:

To fix the other problems, I added a FlowLayoutPanel (which is very different from the StackPanel in WPF, but still serves the same purpose), and made all the relevant bits autosize (it’s always surprising to me when I need to drop back to WinForms, how everything has to be told to autosize and fill empty space).

That’s enough to take care of the output problem, and make the two solutions roughly equivalent (there’s still some differences, as you can see if you run them).

For what it’s worth, this was a real world question from a user at our Virtual User Group this morning, and I just couldn’t help sharing how much easier user interfaces are to write in ShowUI. Clearly a designer like PrimalForms makes laying out the controls easier — but when it comes to the little things, you still have to figure out to make them work, and actually implement your event handlers correctly.

Just for the record, here’s what it would take to implement the WPF solution without ShowUI:

In programming, we call those interactions “events.” An event in WPF covers all forms of user interactions like clicking a button, type in a textbox, or select items from a treeview or listbox, and even less obvious things like when the right or left mouse button get’s pressed down, or let up … or when the mouse moves, of when the control gets focus or looses it, or “touch” and “stylus” events, drag-and-drop events, etc. There are also events that aren’t caused by users, like events for when databinding is updated, when the control is initialized, hidden, made visible, etc.

In ShowUI, all events are handled by assigning scriptblocks to a parameter who’s name starts with “On_” like -On_Click or -On_GotFocus or -On_MouseLeftButtonDown or -On_TextInput … and so on.

Let’s say that you want a quick dialog like this:

You’re going to need to handle the OK button click, of course, but in that scriptblock, you’re going to want to get the text from the textbox, and make sure that it gets returned when the window is closed … and you’re going to want to close the Window!

We’re here to help! Within the event handler script blocks, ShowUI defines a bunch of variables for you to help you handle the event: $this is the source of the event, $_ is the event arguments, and $window is the top-level window that contains your UI. Any named controls in your script are also exposed as variables, so if you started with this script:

You’re going to be able to get the text from the TextBox using $FullName.Text because you know the TextBox has a property named “Text” (since it’s exposed as a parameter for you in the TextBox command), and because now you know that ShowUI creates a variable for all the named controls.

In order to write output from a script like that one, you have to set the Tag property on the top level control (in this case, the StackPanel, which is obviously named “Prompt”). You can do that easily by hand, or you can use the Set-UIValue function.

In order to close the window, you’re going to have to do one of two things: first, you can use the handy Close-Control function, or you can call the Close method on the window. The Close-Control function will look at the “parent” (and it’s parent) to try and find the window that needs to be closed — but if it can’t find one, it will just hide the parent, so if your button were several layers deep (unlike ours), you’d have to specify the top level control as a parameter.

Here’s two versions of what it could have looked like when I was finished:

One thing you’ll notice right away is that I cheated and actually added another event handler too: For the “Loaded” event on the StackPanel. This event handler is called during the initialization of the user interface, and gives you a chance to do things like what I did here: set the initial keyboard focus where you want it (so the user can start typing as soon as the window pops up).

However, if you run them both, you’ll notice another thing: the output is different. In the second example I took advantage of the fact that Set-UIValue will actually call Get-UIValue if you don’t pass it a parameter! The cool thing about Get-UIValue is that if it doesn’t find a “Tag” on the specified control, it will look through the children to find one, and create a hashtable out of the values it finds. So in this case, rather than write the code to get the value from the right textbox and set it myself, I just let the built-in features of ShowUI do their thing.

A bigger example

Of course, in neither example did I need to do anything with the button or with the actual parameters that are passed in to the button’s “Click” event … so perhaps one last (more complicated) example would be useful:

Hopefully, by now this doesn’t need a whole lot of explanation, but let’s walk through it anyway. First of all, if you’re not familiar with them, this script uses the excellent PowerShell Commands for Active Directory from Quest software. This doesn’t represent a full, complete, useful user interface — it’s more of an example that you can hopefully work from (and please, contribute ammendments on PoshCode).

You can see that I used a Grid with four rows and two Columns: with one column “Auto“sized, and one using up all the rest of the UI (you can resize the window to make the fields bigger). The first thing in the grid is the definition of a scripblock which I assigned to a variable $GetGroups. The reason I did that is because I wanted to reuse the scriptblock as the event handler for both the UserName and EmailAddress fields.

Without dwelling a whole lot on it, you can see the last line is the “OK” button which get’s the parent grid and calls Set-UIValue to invoke, as before, the hashtable collection of all the textbox values.

The interesting stuff is in that GetGroup event handler:

You can see that first we call Get-QADUser with the Text of $this field. By using $this, we make it so the event handler will work on both Textboxes, since it will get the text of whatever triggered the event handler. Get-QADUser doesn’t return anything unless it finds a user, and setting the SizeLimit ensures that we won’t end up waiting for it to retrieve “all” the users just because the Textbox was left empty. In fact, the point of that line is to make sure that we matched a user.

On the next line, I’m making sure that either the LogonName or Email of the user that we found matches fully the text that the user typed. This makes sure that the user that we matched is a full match, so we know we’ve gotten the person typing into the form to type a full, complete username or email address.

When it does match, we set the color to Black (in case it was an error and set to Red before), and we call Get-QADGroup to get all the groups that the user is a member of. We set those groups as the source for the $Group listbox, and they’ll immediately show up for the user. And finally, we update the few fields we’re showing from the user object we retrieved earlier.

Of course, when it doesn’t match, we set the text red to indicate an error, and then we zero out the data on the group listbox.

I hope this has helped some of you figure out event handlers in ShowUI — please feel free to ask questions in the comments below or on the ShowUI discussion boards.

An introduction to ShowUI

ShowUI is the next generation PowerShell module for building user interfaces in script. It’s the merger of my previous PowerShell UI project (called PowerBoots) with one by James Brundage, former Microsoft PowerShell team member and founder of Start-Automating (called WPK) which shipped in the Windows 7 resource kit.

If you want to follow along, you need to:

1. Get a copy of the ShowUI Module from CodePlex
2. Install it by putting the “ShowUI” folder in one of your “Modules” folders (list them by typing $Env:PSMODULEPATH in PowerShell v2, and feel free to create the one you want if it doesn’t exist). You should end up with something like C:\Users\Jaykul\Documents\WindowsPowerShell\Modules\ShowUI\ShowUI.psm1
3. Run PowerShell ISE, or use PowerShell.exe with the -STA switch (the best way to do this is to add it to the shortcut you use to launch PowerShell: open the properties dialog, and on the Shortcut tab, add “ -STA” to the Target)¹.

Did I hear someone ask what is WPF? It was introduced as part of .Net 3.0 (and vastly improved in .Net 3.5, and again in 4.0), 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 ShowUI program

This first example is a little bit more verbose than it needs to be, because 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 content parameters: Items, Blocks, and Inlines.

Additionally, each control is aliased without the New- verb, so you could just call Button instead of New-Button … and of course, since our button doesn’t do anything, we could just as easily have used a Label, and written:

Note: “Label” is also the name of an executable for labelling drives in Windows, make sure ShowUI is imported before you run that command.

One last point: ShowUI brings a lot of features from WPK to the table, and one you’ll use a lot is the ability to skip specifying the window and put the -Show parameter on almost any WPF element. This is partly because we’re back to running PowerShell 2.0 with the -STA switch, but in any case, we can now skip the “New-BootsWindow” command, and our examples can be that much simpler.

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 (hint: try resizing the window). Actually, try it with a UniformGrid too. WPF has several other panel containers too: Grid, ToolBarPanel, TabPanel, DockPanel, Canvas … we’ll talk about some more of those later.

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. We can also specify the FontFamily, FontSize, FontWeight, and FontStyle, as well as Foreground and Background colors …

So you see, the pink background is on the StackPanel, which has a (default, 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.

An aside on Typography

ShowUI doesn’t need 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 used previously. So, with WPF we start by selecting a control based on how much text you want to put in it, and how much formatting you want to apply: Label and TextBox are the simplest, TextBlock supports limited text formattings, and FlowDocumentViewer or RichTextBox support full rich content. And of course, Hyperlink supports clicking

For the typography elements, the content model changes a little bit. There are basically two types of typographical elements: Inline and Block elements (where inline elements can’t contain block elements). In fact, he TextBlock Content Model is similar to that of an inline element. 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.

Time for some artwork

In WPF, 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

When you want to start getting clever and overlapping things, you need to use a Canvas container. The Canvas can contain multiple items which are all absolutely positioned, but unlike most 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, and again, if we don’t set them, they default to white. Note that you can use named colors, or you can specify a hex value using “#RRGGBB” or “#AARRGGBB” to set the alpha channel. The StrokeThickness controls the line thickness.

One other thing to notice is that we positioned the Rectangle by using the Margin, but we 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 nearly any shape you want 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

WPF 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 -AsJob, you can actually continue using PowerShell while the image loads. Note: it will load much faster the second time you run that script.

Events

If you were paying attention to the typography example, you’ll have noticed that we introduced event handling without making a big fuss about it. Event handlers in PowerBoots are specified in much the same way that Properties are, except that 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 variables that point at the control(s) you want to affect. In ShowUI event handlers, you get a $this variable which points at the object that caused the event, a $_ variable which is the event arguments, and a $window variable for the top-level window … you also get variables for each named control in your window.

WPF Elements all have a Tag property which can be used to store any object, so as you can see in the previous example, you can use that to keep track of things … but more importantly, the value of the Tag on the top-level control will be output. In other words, when the window is closed, this example actually outputs to the PowerShell pipeline how many times you clicked the button.

Working with User Input

There are helper functions in ShowUI for working with that output value: Set-UIValue and Get-UIValue, and Get-UIValue is particularly helpful because if the control it’s called on has no value, it collects the values of all the child controls, so you can use it to output a whole form at once:

I’ve made this example more complicated than it needed to be to demonstrate some best practices. We could have made it much simpler by using a UniformGrid control instead of a GridControl, thus avoiding needing to set the -Row and -Column special parameters, but I wanted to show those to you anyway, and the form looks a lot better when the two columns can have different sizes:

You’ll notice how easily I specified the width of the columns, but the COUNT of the rows in the Grid panel. If you provide an array of values, they’re converted to GridLengths, but if you provide just one, it’s treated as the count. You can make grid columnds and rows AUTOmatically size to their contents, and you can make them * width to make them take up any extra space. You can even split the extra space by setting * on more than one column (and specify the proportion by using numbers, like: 1*, 2*).

I should also point out that if you use MinHeight and MinWidth instead of the Height and Width values, your controls will be able to size up to fill space when the window is resized! Try that script with Width and Height instead and resize the window to see the difference.

We used the Set-UIValue shortcut in this form, which brings up another point: when creating data forms, you only need to name the controls you want output from. Then you’ll be able to just call Set-UIValue on the parent to collect all the values from the controls and output them as a hashtable!

Finally, remember your defaults: set the focus to something so the user doesn’t HAVE to click to get started, and set a button to -IsDefault with a On_Click handler so that when the user hits enter they can submit the form.

Further directions

There’s a lot more possible with ShowUI: we can use gradients for colors, create data templates and styles, and even make chromeless windows, but you have the basics for getting started already.

This first release of ShowUI is still missing some features from both WPK and PowerBoots, but we’ll get to them as we progress. For now we’d like to invite you to come download the latest release, and write up or vote up the features that you want the most in the next version. Keep an eye on the release page and on the discussions and we’ll be cranking out new releases on a monthly basis for now.

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

¹ The -STA switch is necessary because the .Net framework requires the STA threading model in order to do graphical user interfaces. PowerShell ISE doesn’t require it because unlike the PowerShell.exe command console (which is a Win32 native “console” application that hosts the .Net framework), PowerShell ISE is a .Net framework “graphical” application, and is therefore running in the STA model already.

• PowerPoint Deck

• PDF Deck with notes

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:

This is actually a bit scary, because you can load sort-of … anything To prove it (you’re gonna love this … I should take a video, really, but it’s time for bed, so this will have to do): check this out Beat that!

So yeah, I have this control written from an earlier project which creates a task list with live preview images. When I say “live previews” I mean actually live, like on the Vista Alt+Tab: if there’s a video playing, you can watch it in there (of course, it dies a horrible death on XP, but I have other code for that).

As a side note the TaskBar2.panel stuff is from the TINS release I made months ago, there’s several fun .panel files in there … but you have to load a bunch of the TINS assemblies first, I didn’t distinguish which ones, I just did:

Of course, in .Net 3.5 the RichTextBox has the ability to go ContentEnabled="true" which should allow those things to be actual controls you can click to switch active task, right-click to get a task menu, etc (although I haven’t tried that yet). We might just have to upgrade

Anyway, it’s past time for bed, so I’ll preempt complaints about how this isn’t ready for release yet with this quote:

I don’t have to take this abuse from you; I’ve got hundreds of people waiting to abuse me. — Bill Murray, “Ghostbusters”

Visionary insights come from thinking more about human needs than technological possibilities. Ben Shneiderman Leonardo’s Laptop: Human needs and the new computing technologies

Shneiderman writes about the success of Palm handhelds:

The surprise was that users were willing to learn a variant of the English alphabet called Grafitti so that they could enter data … [a great surprise] in light of the [earlier] failure of the Apple Newton, which offered recognition for handwritten words…. Most users feel responsible for Graffiti stroke recognition errors, whereas they tended to blame the Newton for word recognition failures.

I would like to think that the lesson is something about the simplicity of the Graffiti stroke system, vs. the complexity of handwriting recognition … but I’ve used a Palm, and I haven’t found the Graffiti system is astonishingly accurate, so I think that Shneiderman has given us the right answer: users feel responsible.

So, the real lesson is very simple, and it’s about expectation setting. Palm, by telling you up front that there was no handwriting recognition, but that instead you needed to communicate with the tool using these special strokes … put the burden on you. Apple, by telling you the tool could read handwriting, put the burden on the tool. Of course, there were obviously many other factors involved — and timing was certainly one of them. But it seems that the important lesson is about controlling the expectations of your users.

What we learned is that people are willing to put up with quirky software if they can be convinced that any problems are their own fault. Based on what we know about users, you would expect them to be annoyed when they first start using the tool at how hard it is (ok, I know it’s not that hard, I have a Palm — but it’s significantly harder than writing in a Moleskine). Because of the way that it’s marketed, pitched, and explained … the users of the Palm blame themselves, and thus don’t get angry at the technology.

Incidentally, this expectation stuff might help fans of Linux and Mac OS X understand the current computer marketplace. In fact, I’d wager that this is the only way that Windows’ market share dominance can be attacked. If you can figure out how to advertise (without insulting Windows users) so as to raise expectations of software … you may be able to reach a point where the majority of people will become dissatisfied with their current platform.

Technorati Tags: lessons, newton, apple, palm, user experience, friction, expectations

The Vista Thumbnailer is a really slick little app that shows off some of what Vista can do … and some of what WPF can do. I’ll write more about it in the morning, because there’s some interesting things I learned in the coding of it, but in the meantime, you can download Vista Thumbnailer (7-Zip file with a config file). The only thing you really need to know is that there’s a hotkey: Win+X which will bring Thumbnailer back to the foreground even if it’s minimized in the tray. I’ll make the hotkey configurable in version 2, but for now you’re stuck with Win+X. The rest you can figure out from the screenshots (0 1 2) and by reading the tooltips on the buttons.

Play around. Let me know what you think.

(Oh, source code is here with your usual choice of BSD/Ms-PL/GPL)

[New] Edit: Continuing

So … I’ve had a lot of questions about this app during it’s development (from a few friends in our IRC channel) so it’s clear that I should try to at least give the highlights of how it works.

Thumbnails

By now you’ve probably seen more than your fill of screenshots of Windows Vista’s semi-transparent windows, and maybe you’ve had a chance to try Vista and seen these live-updating thumbnails on the Alt+Tab window, the Flip3D Win+Tab task switcher, and even the task-bar’s mouse-over (or Win+T) popups. All of this is possible because of the way Windows does desktop compositing using a new Desktop Window Manager. This DWM is actually a process which runs all the time when you have the “Aero” interface turned on, but it’s also an API exposed through dwmapi.dll … and one of the deepest fundamental changes to the way Windows work in Vista. Let me quote from “one of the developers” blogs:

... The way an application gets pixels on the screen has fundamentally changed. [In the past] applications were asked by Windows to paint their visible region, and they would paint directly to the buffer that was to be displayed by the video card. With Windows Vista, applications are asked by Windows to paint their entire surface to an offscreen surface (alternatively known as a bitmap, buffer, or texture), and it’s up to the DWM to take all of these offscreen surfaces, and “compose” them together to the onscreen buffer.

Because the windows are rendered “offscreen” and without regard to what part of the window might actually be visible … the visual representation can be reused in many places very cheaply — that is, since the visual representation is just a cached picture, there’s very little CPU cost involved in repainting it in many places … and the caching and repainting are easily handled by the DWM. Now, the DWM also does lots of other cool things, like using DirectX and hardware accelleration to do all this extra rendering of these cached surfaces, but despite appearances, this isn’t really an article about the DWM — we’re here to talk about JUST the thumbnails. Greg Schechter again:

Thumbnails in the DWM are not static snapshots of a window. They’re dynamic, constant connections between a thumbnail source window, and a place on a target window that that source window will get a “thumbnail rendering”.

Basically, the APIs in the Desktop Window Manager allow you to ask for a certain portion of one Window’s screen to be painted over (at some specified level of opacity) with all or part of the contents of another Window’s screen. In every sense, the thumbnail is just as live and up-to-date as the actual window (since it is, in fact, being painted by the same process).

So anyway, what I did is I took a “Thumbnail” class from Douglas Stockwell and enhanced it a bit … it’s still not quite perfect, but it’s trivially easy to use now: just pass it a Window handle and it hooks itself up and renders within it’s available bounds — mostly.

Glass Effect

The Vista Thumbnailer app also showcases a couple of other slick API features. First, I added a couple of simple wrappers to DwmExtendFrameIntoClientArea and DwmIsCompositionEnabled so that you can easily get the translucent “glass” effect on your whole window, or write, for instance: if( !NativeMethods.IsCompositionEnabled ) { MessageBox.Show( "Sorry you can't use this feature!" ); } …

Hotkeys

I also wrote a global hotkey manager class which can be easily added to WPF applications that want to register global hotkeys. VistaThumbnailer only has one, to focus it (you can change it by editing the .config file).

These are global hotkeys, not like the “Ctrl+O” for opening a file, but like the Win+R to bring up a run dialog. They’re registered through Window’s RegisterHotkey and UnregisterHotkey APIs, and you get notified of them via window messages (but my HotkeyManager class will handle the WM_HOTKEY message for you). Here’s the short-form for how to use them (you can grab the source if you’d like to borrow the class, but I’ll be re-releasing this in a few days with some enhancements I’ll detail below).

I want you to notice that I had to create my own Keys enumeration in this, because the WPF developers unbelievably chose to use an ordering for their Key enumeration which is inconsistent with the Windows API ordering. You could use the System.Windows.Forms enumeration, but that would require adding a reference to the Forms assembly in your WPF application just to get a silly enum! I have to say that this seems to be absolutely the WORST design decision I’ve seen in the .NET Framework — not only are they duplicating enumerations which exist elsewhere, but they couldn’t even copy-and-paste it in order?

Chrome Free Windows!

I thought I’d mention this, just in case you haven’t seen it before. Irregular shaped windows are trivially easy to do in WPF. All you have to do is add the following attributes to your Window tag: WindowStyle=“None” AllowsTransparency=“True” Background=“Transparent”

Further Development

DWM API Thumbnails

There are still a few tweaks that need to be made to the Thumbnail Image control. It doesn’t adjust when the source window is changed until you resize the window (because it doesn’t check the size except when WPF asks it to) and I’m not sure if it’s possible apart from re-checking the source window shape on a timer. I’m a little afraid that I’m leaking the thumbnail window so I need to wrap them in a Safe Handle, and override OnUnloaded to clean up.

I’m also curious if there’s a way, in the DWM api, to get these thumbnails batched into a video or saved to an image handle so you can use them for screenshots … I’ll have to take some additional time to research that.

Hotkeys

There’s also some changes I want to make to the way my hotkeys class works. Right now you have to hang on to your Hotkey objects in order to be able to process the hotkey events correctly (unless you only have a single Hotkey) ... and it’s not possible to use a switch statement on the event, so if you have a lot of hotkeys, it gets a bit ridiculous. I initially did this because I didn’t like trusting the user to come up with unique Hotkey Id’s, but now I’m thinking that it might be better if you could use just the Ids and create yourself an enumeration for them. I need to play with this, because one of my key use scenarios is having windowless plugins be able to register and process their own hotkeys — which makes enums not completely safe, because different pieces of code are dynamically creating hotkeys.

I also don’t like not being able to register the hotkeys during construction. My first attempt to fix that is a version of this HotkeyManager (which I’ll release shortly) that creates it’s own window — this means you don’t have to worry about calling it in SourceInitialized, but it’s a pretty expensive fix if you’ve already got a window. I’m going to try doing it another way — where hotkeys registered before the handle is initialized will be queued for registration later, and this should be a better solution in most cases. I do have a System.Windows.Forms version (which I will release with all the other versions) that doesn’t have this problem (because with Windows.Forms you get a window handle on construction), but again, I don’t like including that whole assembly for something fairly trivial.

Hopefully I’m going to get better at these writeups as time goes on, because I feel like this one is a bit rambling. Questions and comments are welcome!