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

rad

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.

brain

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)

Enjoy!


WPF vs. Windows Forms

September 5, 2007

During my WPF presentation at the NYC .NET Developer Group, someone asked me a simple yet difficult question.  Allow me to paraphrase: “I work for a bank’s IT department.  We build Windows Forms applications which basically just show large tables of numbers, allow the user to sort them, edit them, etc.  There is some simple business validation in place, and a few other standard LOB-application things you’d expect.  We have no need for UI candy, animations, 3D, etc.  Why should we use WPF and what can I say to management to convince them that we should use WPF in upcoming projects?”

When he asked that question, I did not have an answer for him.  Ever since that night I have been thinking about it, and even had the chance to discuss it with Tim Sneath; who had some excellent perspectives on the question.  Here is my much delayed answer for the fellow who asked that question.  Please note that the answer I’m about to give does not necessarily reflect Tim Sneath’s opinion of this topic, nor am I claiming that he supports the view I’m about to express.

WPF is not intended to replace Windows Forms.  I used to think it was intended to be a replacement for WinForms, but it is not.  WinForms is still alive and well, and will continue to be enhanced and supported by Microsoft for years to come.  WPF is simply another tool for Windows desktop application developers to use, when appropriate.  If the type of applications you develop would not benefit from the features found in the WPF platform, then perhaps WPF is not the correct platform for you to use. 

So when should one use WPF instead of WinForms, and vice versa? 

First off, WPF is not just for applications which simply require “eye candy.”  That is the most common and frustrating misperception about WPF which I’ve encountered.  Sure, WPF has a lot of support for flashy visuals and animations.  But that’s not all it’s good for.  If you’ve worked with WPF for any substantial period of time you are probably well aware of this fact, so I won’t keep harping on the issue.

WPF is an especially great platform to use if your applications involve various media types.  For example, if you need to incorporate video, or documents, or 3D content, or animated transitions between a sequence of images, or a combination of any of the above.  WPF is also great if you need to create a skinned user interface, or if you need to bind to XML data, or dynamically load portions of a user interface from a Web service, or want to create a desktop application with a Web-like navigation style.

Another great reason to use WPF is if you have a team of developers who are bored with WinForms and are itching to get into something new and cool.  Of course this is not as powerful and compelling a reason from a business perspective, but nothing promotes employee retention better than keeping the employees interested in their jobs.

WinForms definitely still has a role to play, despite the fact that WPF has hit the scene.  If you are building applications with no need for the extensive modern functionality in WPF, then there is no compelling reason to leave behind a time-tested developer-approved platform.  WinForms certainly has more 3rd party controls available, online resources, developer communities, etc. than WPF currently does.  It’s much easier to find WinForms developers than WPF developers.  Also, WinForms currently has a much better design-time experience in Visual Studio than WPF.  That fact alone is a very compelling reason to stick with WinForms for a while.

Lastly, don’t forget that it is possible to use WPF controls in a WinForms app, and WinForms controls in a WPF app.  If you have a substantial investment in a WinForms code-base, but want to use some aspect(s) of WPF, you can leverage the interop support to make that possible.  Just be sure to read up on the limitations involved with WinForms-WPF interop before getting too far down that path.


When will WPF become a mainstream platform?

August 9, 2007

I have been involved with WPF for over a year and a half now.  I’ve seen it grow from shaky CTP builds into a great v1 platform.  Ask anyone who has worked with WPF in a non-trivial way, and you are bound to hear that it is leaps and bounds better than Windows Forms.  The platform is publicly released now and is a truly great technology, but its adoption rate is still quite low.  I’ve read numerous reports that WPF is not gaining much traction in the software world yet, and a quick search for open WPF jobs verifies it (no, I’m not looking to change jobs!). Why is WPF not being rapidly adopted?  Here are my thoughts on the issue.

Beta?  We don’t use no stinkin’ Beta!

Working with WPF currently requires you to use a beta version of Visual Studio, either VS2005 with the “Orcas” extensions or a beta build of VS2008.  Most companies don’t want their development staff building products with beta versions of Visual Studio.  Even though WPF v1 has been publicly released, the tools for working with it are still in beta.  That’s probably the biggest deterrent for most shops.  At this point, only AlphaGeeks are willing to install beta builds of VS2008 on their home machine and play with WPF in their free time.

DataGrid?  We don’t have no stinkin’ DataGrid!

WPF v1 is missing a lot of the bread and butter support for most line-of-business (LOB) apps.  The canonical example is the fact that there is no out-of-the-box DataGrid control.  Beyond that, there is no masked editor, no date/time picker, and others.  For a lot of people this is a major turnoff.  WPF v1 is just not “there yet” as a platform for developing LOB apps, many would say.

Graphic Designers?  We don’t have no stinkin’ Graphic Designers!

In my opinion, Microsoft’s marketing team pushed the “designer-developer workflow” aspect of WPF way too much.  The whole idea that WPF allows graphic designers and developers to work closely together, with XAML as the common format they share, is not that important to many software shops/IT departments.  Many shops don’t have graphic designers, so this whole aspect of WPF is completely unimportant to them.  The marketing around WPF makes the platform seem to be important for companies that create highly specialized user interfaces (i.e. Times Reader), but not standard LOB apps.  That’s an unfortunate misperception, and couldn’t be further from the truth.

Tomorrow, tomorrow, I’ll love you tomorrow.

Now that I’ve set up all the ducks in a row, let’s blow their little heads off.  🙂

The obvious answer to the Beta problem is simply to wait for VS2008 to be officially released.  I predict that once VS2008 hits the market, WPF will start to gain a lot of momentum.  As shops start installing the new Visual Studio on their dev machines, and developers start exploring WPF there will be a surge of interest in the platform.  People will start considering WPF for their next app.  I think that will be the most important catalyst for WPF adoption.

The DataGrid problem has already been solved somewhat.  There are third-party WPF grid controls out there today, by companies such as Infragistics and Xceed.  In fact Infragistics has also created a masked editor, date/time picker, and other common controls that WPF does not have by default. 

I’ve heard rumors that Microsoft is going to develop a DataGridView replacement for WPF, but who knows when/if that hits the street.  The more general problem of WPF not being LOB-friendly is the main thrust behind the next release of WPF; which is part of the .NET 3.5 Framework.  Since 3.5 will be included in VS2008, the first non-beta version of Visual Studio which natively supports WPF will have all the new LOB-friendliness in it.

Lastly we have the Graphic Designer problem.  There is not much that Microsoft can do to remedy the fact that many companies don’t have such people around to make WPF apps look great.  However, I think that third-party vendors can save the day here.  Basically they have their graphic designers create eye-pleasing themes and then wrap them up in resource dictionaries which can be used by any WPF application.  Infragistics already has created what they call “ThemePacks” which allow you to do this.  I think this is a great idea!

In conclusion, I think there is still a ways to go before WPF is the de facto UI platform for most .NET shops.  Until then, I think it is wise to keep learning about WPF.  When there starts to be high demand for WPF developers it will be the people involved with the platform now who will be the highly paid experts. 😉


WPFpedia by Actipro Software

June 15, 2007

I recently discovered WPFpedia.com.  It is a site produced by Actipro Software which contains links to a wealth of WPF material, grouped into several categories and sub-categories.  The main categories are:

I have been exploring their content and am quite impressed at how many useful things they have added to their site.  They even said some kind words about me and my blog (thanks!).  It’s great to see that WPF is starting to have an active and helpful community these days. 

Once Visual Studio 2008, with all its rich support for WPF application development, hits the market I suspect that WPF will really start to take off.  If sites like WPFpedia keep amassing quality content and building a community around WPF, we will probably start to see more and more job opportunities for WPF developers.  Now wouldn’t that be grand? 😀