First WPF Application

Media.Copy

This summer, August to be more precise, I spent some of my vacation learning WPF. Whilst my wife wasn’t happy about this, as most things computer related and my time, it was really a lot of fun with dashes of excitement, loads of frustration and a case of beer. Like most people I don’t do things just for the sake of it I wanted to solve a problem that I had. Since the late nineties I’ve been burning my CDs to different formats and the directory structures had gotten out of control. My collection is well over 250 CDs so it is no small task to try and organize it by hand (read file copy).

Removed Source Code Link until I Find Another Place To Host It From 

Problem: My directory structures did not match the CDs that were ripped over the years to my liking. Instead I wanted it to be arrange by Artist / Album versus having all tracks in a single directory.

Solution: Write a program that will read the ID3 tags and then create a series of directories and copy the files where they need to go using WPF as a front end.

Ignorance: Writing a WPF application should be very similar to writing a smart client application.

Warning: This program was written quickly and not intended to show how to properly code things under the UI. Comments related to “why did you hardcode this or that, you should have made it more extensible, blah blah blah” will be promptly ignored. J

 

The first thing I did was grab my trusty pen and paper to sketch out a few UI designs and list features that I would like to have. This took about 30 minutes or so and then my first step would be to get the thing working as a smart client application and then port it over to WPF. This way I know the underlying code will work and only the UI needs to be touched. That part took a few hours of searching around the internet for source that can read MP3 and WMA file, putting that into a project and then bolting together a quick UI using my design. Done and it transferred files as expected.

Now the port to WPF…

Where the hell is my designer???

For us dev types I found Expression Blend to have a steep learning curve. The beer may have loosened my tongue however it did not do much for my patience. Getting up a basic design surface thru nesting is not easy to accomplish for first timers. I lost count how my times I hit Cntl-Z when doing any type of modification. After a day my UI looked way better than the smart client version and I thought to myself: WPF does indeed rock. Hit compile and time to test…

It found the files and displayed them all in the ListView as expected. Now I just have to hit the Transfer Button and watch the gloriousness that is WPF update the UI. Wrong. WFP is STA and the usual smart client tricks for UI updates didn’t work. WPF turned into WTF and then I had to completely re-write things to make them multi-threaded. Talk about an extra task that I didn’t need to go thru previously. Moral of the story is you have to think about threading when doing anything that is computationally intensive (read more than 100ms) or be prepared for the great application hang. No nicety such as Application.Refresh() or similar to be had. Well, everything is now working and I just today updated it to Visual Studio 2008.

The source code is online via my SkyDrive if anyone wants to check it out. It contains both the UI and code so you'll be off the races in little time. If you make some cool changes let me know and shoot me a link to the updated source!

I’ll do a follow-up post that contains the two books I bought, the three day online course I casually watched, and the internal emails (sans aliases) that got me to my first WPF application. J


Posted Jan 04 2008, 10:00 AM by mark-baciak

Comments

Ian Griffiths wrote re: First WPF Application
on 01-13-2008 1:16 PM
What "usual smart client tricks for UI updates" didn't work when you tried them?

WPF supports the AsyncOperationManager, and it also supports the SynchronizationContext. These are what I've always thought of as the usual tricks - for example, these are what the BackgroundWorker is based on, and that's why the BackgroundWorker works fine on WPF even though it was designed for Windows Forms.

Also, if it's just property updates you need, if you're implementing INotifyPropertyChange you don't even need to take any steps to get updates done on the right thread. WPF detects when property changes raised by this interface occur on the wrong thread and handles the cross-threading for you.

It's only if you're updating the UI directly, or if you're relying on list binding (unfortunately, WPF doesn't cope with cross-thread INotifyCollectionChanged events) that you need to manage the threading by hand.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?