Bach to the Future

July 3, 2008

Every once in a while, I post a recording of myself playing the piano.  Today is one of those days!  Please excuse the crappy recording quality, I have no recording/mixing tools (or skills!).  I have been working on the C Minor Prelude from the first book of the Well-Tempered Clavier, by J.S. Bach.  Whenever I know that I’m being recorded, I inevitably make mistakes that never occur when playing sans audience.  I know there must be some analogy involving a tree falling down or Heisenberg here…

Anyways, if would like to hear what my musician alter ego has been up to recently… wtc-book1-cminor-prelude

If you like that piece and would like to see one crazy-talented person play it on two electric guitars…  click here


Good old fashion image animations in WPF

April 23, 2008

As I tried in vain to fall asleep at a reasonable hour tonight, it dawned on me that something is missing from the standard WPF literature. Most of the animation examples show off the awesome built-in support for animations, which means changing a property’s value over time. What I felt was missing is an example of how to create an animation by showing a sequence of images in rapid succession.  Ya know, like Mickey Mouse.  So I got out of bed and made one!

I opened SnagIt, created 37 separate images, saved each one with a name like “001.png”, and then dropped them all into a new project in Visual Studio. All of the image files are copied to the project’s output directory, instead of saving them as resources in the assembly. After assigning the Window’s Content an Image element in XAML, I wrote the following code:

I just love using LINQ!  It makes data processing so much easier.  If you haven’t already done so, I highly recommend you read Joseph Rattz’s “Pro LINQ – Language Integrated Query in C# 2008“.

When I run the app, it looks like this:

If you want the source code, you can download it here. Be sure to change the file extension from .DOC to .ZIP and then decompress the file.

Why use WPF if it is not RAD yet?

April 21, 2008


I have been heavily involved with WPF for years now. When I first started out with “Avalon” it was hardly a blip on the .NET radar. After just a couple of years the crickets have been replaced by a rock concert, and the intensity just keeps growing. For a WPF geek, such as me, this is great news!

My numerous encounters with people using WPF have lead to me to conclude that the platform is finally gaining traction in the .NET universe. WPF has been picking up momentum for a while in the financial services world, in particular. I have also met quite a few people using WPF in the state/local government sector, the retail sector, entertainment sector, and quite a few others.

But, wait a minute…why are people moving to WPF? Visual Studio 2008 offers rather weak design-time support for WPF. The lack of drag-and-drop magic in VS2008 essentially kills any hope of the rapid application development (RAD) that so many software shops hold near and dear. Why are people leaving RAD for MAD (manual application development)? In this blog post, we will discuss why WinForms and ASP.NET developers have decided to move on to WPF. Note, everything in this post is based on discussions I have had with people, but is certainly not the “definitive” explanation by any means.

The most obvious reason that people are now moving to WPF is that Visual Studio 2008 natively supports WPF development without requiring any extensions to be installed (i.e. the Orcas extensions for VS2005). Even though the WPF design-time experience still leaves much to be desired, the fact that it is part of VS2008 is important for many software shops. Most companies simply will not base their software development on pre-release bits; and I do not blame them.

In the previous paragraph, I mentioned that Cider (the WPF designer in Visual Studio) leaves much to be desired. Compared to the high-productivity RAD tooling support to which Windows Forms and ASP.NET developers are accustomed, it might seem surprising that anyone would drift away into the not-so-RAD world of WPF. Let’s take a closer look at exactly what this means.

Moving from ASP.NET to WPF is not too radical of a shift (so I’ve heard), in terms of tooling. Both platforms involve a markup file with an associated code-behind file. In both ASP.NET and WPF, the developer expects to go into the markup file and tweak the tags by hand. The design surface can only get you so far. From a tooling perspective, the shift from ASP.NET to WPF is not as radical of a change as for WinForms developers.

For those of us who approach WPF with a strong background in Windows Forms, however, you are pretty much required to remove your brain from your skull, rotate it 180 degrees, and put it back in.


This stems from the fact that WinForms developers are trained to never look at the designer-generated muck that is written for the Forms that they whip together in VS. The idea of working with markup that represents a UI is foreign to most WinFormers. Trying to move from a world where the serialization format used by Visual Studio to represent a UI is irrelevant, into a world where you are hand-coding XAML to get a UI together represents a significant mental shift.

This brings us back to the original question. Why are people moving to WPF at an increasing rate? I have heard several recurring themes when I ask people this question. Below I summarize each theme, and try to explain the rationale behind them.

Many people who moved from WinForms to WPF have told me that they are concerned about Microsoft gradually phasing out WinForms and concentrating their new developments and customer support into WPF. Many people feel that sticking with WinForms is just asking to be left in the dust. That is a very forward thinking idea, though I obviously have no idea how long it will be before WinForms is retired.

Another common theme I have noticed is that people are leaving WinForms for WPF because they want to incorporate advanced data visualizations in their programs. There seems to be quite a lot of interest in the possibilities of charts and graphs that a vector-based rendering system, which supports 3D, has to offer. Creating animated 3D data visualizations in WinForms is not exactly something that the average developer can do, but in WPF the barrier to entry is significantly lower. In my mind, that’s a very good thing (unless you happen to be making excellent money by creating advanced 3D data visualizations via GDI+).

The other common thread I’ve noticed is that people move from WinForms to WPF because they find certain aspects of the platform appealing. For example, many folks I meet tell me that the WPF data binding system alone was compelling enough for them to make the switch. I completely understand that!! From a developer’s perspective, things like triggers, routed events, rich data binding, and commands are extremely useful and addictive.

The last thing I have heard people say, but not quite as often, is that they want to have an easier way to involve a Visual Designer in their project. People who say that are typically working on a product, as opposed to an internal application for a company. For them, the idea that their aesthetically-challenged developers will not be responsible for designing the user experience is a powerful selling point for WPF adoption. Once again, I completely understand that! 😉

The reasons why ASP.NET folks are moving to WPF overlap with the reasons listed above, for WinFormers. In addition, I have heard that some Web developers are just plain sick and tired of dealing with browser-incompatible HTML and CSS. I have met Web devs who originally got into Web programming because it made the deployment of their applications much simpler. They soon discovered that they traded the simplicity of development for simplicity of deployment. Pick your evil…

The other major reason that I hear of ASP.NET developers getting into WPF is so that they can get a jumpstart on Silverlight. Since Silverlight is planned to be a subset of WPF, many people find value in learning WPF now, so that they can apply that knowledge to Silverlight once it is officially released. I think that is a very wise plan.

What about you? Why have you started using WPF, or not? What are the key factors in your rationale for adopting or avoiding WPF?

Deleting an image file displayed by an Image element

February 21, 2008

This blog post discusses one way to deal with the fact that, by default, a BitmapImage object holds a lock on the source image file. Along the way we will see what inspired this solution.

I have been working away on Podder, my WPF podcast player. Grant Hinkson, my favorite Visual Designer in the world, has spent some of his scarce free time creating a truly phenomenal skin for Podder. His work has revealed shortcomings and oversights in the Podder design, which I have been diligently working on and resolving.

Every podcast has an associated image, which is linked to via the podcast’s RSS feed. Grant’s Podder skin represents a podcast by showing it’s image. When I first added in support for providing the image of a podcast, I simply exposed a property on my Podcast class that returned the URL of the image. This worked OK for my skin, since it only shows one image at a time. For Grant’s skin, however, this did not cut it. His UI shows multiple podcast images at the same time. When the app first loaded with his skin applied, it would take quite a while for those images to be downloaded and displayed. Subsequent loads with his skin, during the same run of the app, would be fast because WPF caches images by default.

I decided to address this issue by saving each podcast’s image to disk, and then always load the image from disk (instead of downloading it every time you run the app). Getting the image saved to disk was easy:

Image File (download)

The tricky part was a little more subtle. When the user removes a podcast from Podder’s list of podcasts, I feel morally obligated to delete that podcast’s image file from their disk. I suppose it isn’t truly necessary, but I’m not a fan of apps that lazily leave garbage floating around on my disk, eating up space.

This moral quandary resulted in a call to File.Delete(theImageFile). Unfortunately, this did not work. It turns out that the BitmapImage, which is used by an Image element, holds a lock on the image file that you pass as it’s source. If you try to delete the file, an exception is thrown letting you know that you’re being a very naughty developer.

Naturally, the first thing I did was search the Web for more info about this problem. I came across an excellent solution for the problem here. Ralph’s solution involves a custom value converter that adjusts the BitmapImage’s caching behavior, so that it does not put a lock on the image file after the image has been loaded. That’s a very clean and simple solution, but I didn’t want to use it. One of my goals in designing Podder is that it should be as simple as possible to skin it. I’m actually toying with the idea of hosting a competition where people make their own Podder skin(s), and then submit them as entries to be judged and possibly awarded prizes. So I need to keep the skinning process as simple as possible. Having to use some obscure value converter on Image sources does not jive with that objective.

I was stumped. I needed to be able to delete image files for podcasts that were removed from Podder, but attempting to delete an image file resulted in an exception being thrown. What to do? I stepped away from the computer, sat down at the piano, and improvised. The solution dawned on me after playing this lovely little tune:

Josh Smith Piano Improv [2-21-2008]

In an inspired moment, I ran back to my laptop and modified my PodcastImageCache class a bit, so that instead of attempting to immediately delete an image file when told to, it stored the image file path in a list.

Image File (pre-delete)

I added the PodcastImageCache object to the application’s object graph that gets serialized by the BinaryFormatter as it shuts down. When the PodcastImageCache object is serialized that list of image file paths gets saved, too. I then used the magical OnDeserialized attribute to specify a callback to be invoked when Podder starts up again, and the PodcastImageCache object is deserialized.

Image File (delete)
Since the object graph is deserialized before the UI has a chance to come back to life, I am certain that none of the image files will be locked by the UI at the time this code runs. Perhaps this solution is overkill for most apps, but if you need to maintain absolute simplicity in the UI layer then this approach has value.

The importance of learning Expression Blend

February 18, 2008

A few days ago I was visiting the Infragistics headquarters.  I set aside half an hour to stop by Grant Hinkson‘s office.  Grant is the Visual Designer working on a new skin for Podder.  I wanted to check in with him, and work through any issues or questions that might have cropped up during his work on his new Podder skin.  I had a WPF revelation within those thirty minutes.

For this project, Grant is acting solely in the capacity of Visual Designer.  He is a good Developer, but I don’t want him to need those skills for this project.  My objective is to design Podder in such a way that he, the Visual Designer, never has to write a line of code.  Naturally, this means that he is living in Expression Blend to get his work done.  As we worked through little issues and gotchas, I was amazed at how fluent Grant is in Blend.  I must admit, I never use Blend.  He was flying through the menus, dropdowns, panels, etc. so quickly that I could not follow along!

What amazed me even more was the thought processes he went through to get his work done.  As he expertly navigated through Blend, he was saying things like “We’ll need to Storyboard that…I’ll just record a Timeline for this…Now I’ll just trigger the transition off that event…We’ll group those elements together…”  I never, ever say or think things like that when working with WPF.

This experience made me realize that Visual Designers think about WPF in a very different way than Developers.  So different, in fact, that there is a very real potential for a communication barrier to arise between the development staff and the visual design team.  Luckily for me, Grant is an accomplished WPF developer, so we were both pretty much on the same page.  However, it is easy to imagine working with a Visual Designer who does not have the development experience, and having trouble finding a common ground of shared concepts to discuss.  The further away from “visual design” you go, the more murky the communication can become.  For example, how do you discuss the proper way to create a declarative data binding with someone devoid of development experience?

I now believe it is imperative that WPF developers are at least comfortable using Blend.  Even if you have no intention of using Blend on a regular basis, it will prove beneficial as you interact with people who live in Blend.  The thought processes of getting work done, the terminology/lingo, and the artificial limitations imposed by Blend are all things that we, the developers, should know about.  Not only that, but it is a very interesting and powerful tool!

I’m excited to learn Blend!

Bach by popular demand (again)

January 9, 2008

In my previous post I took a little break from WPF to post a recording of me playing a Bach composition on the piano. I’m having too much fun to stop!  I made another recording, this time it’s the Prelude to Bach’s first keyboard partita, in B-flat major.  For some reason, toward the end of this recording it sounds a little strange, like someone passed it through a wah-wah pedal.  Oh well…enjoy!

Prelude in B-flat major (as played by Josh)

Bach by popular demand

January 9, 2008

I meet a lot of people who are into WPF.  It’s funny how many of them are interested in the fact that I play Johann Sebastian Bach‘s keyboard music on the piano.  Bach has been an obsession of mine since I was a little kid.  I’ve been playing the piano since I was five years old, and have been in love with Bach’s music since around then.

Quite a few people have asked me to send them a recording of me playing a Bach piece.  I have a Yamaha Clavinova CLP 240, which is a fantastic digital grand piano.  Recently I realized that I can create semi-decent recordings of me playing the piano and then save them as MP3 files.  So I decided to satisfy the curiosity of all those people who, for whatever strange reason, want to hear me play some Bach.

I wish I had more time to practice the piano, but being obsessed with WPF kinda gets in the way.  The performance is pretty good, but there are definitely things about it I would like to improve.  Unfortunately I’m not sophisticated enough at this stuff to figure out how to edit the audio file. 😉  Alright, enough excuses for my shortcomings.  Here is a recording of me playing the Rondeaux from Bach’s second keyboard partita, in C minor: Rondeaux in C minor (as played by Josh)