Mole now has editing capabilities

December 31, 2007

Karl and Andrew have taken Mole to the next level.  Now you can edit properties and fields of an object, and those modifications are persisted!  I was only marginally involved with this new feature, mostly testing and giving feedback, but I’m really glad that those two guys took the time to see it through to completion.  This is really amazing stuff, and I highly recommend you check out the new article and download the latest bits.  Here is the new article:

Visit to learn more about Mole.

Happy New Year!  😀


A Configurable Window for WPF

December 27, 2007


Any application that people use often should be as convenient as possible.  One of the most expected conveniences of a desktop application is that the size, location, and state of the application’s various windows persist across runs.  If I resize a window, move it to the left side of my screen, and then close it, the next time I open that window it should be the same size and be at the same place on the left side of the screen.  It would be great if WPF provided that functionality for us, but it does not.  This post introduces a base window class that automates this for us, so that every window in our applications gets this functionality free.

What is involved?

The recipe for this dish involves:

  • 1 lbs of an abstract window subclass called ConfigurableWindow
  • 1 cup of a ConfigurableWindowSettings class that knows how to load and save the window settings
  • 1 dash of a ConfigurableWindow subclass which overrides the CreateSettings method and returns a ConfigurableWindowSettings object
  • 4 delicious properties in the Settings.settings file that are used to persist the window settings

This recipe serves one window.  For every additional window that needs to have its settings persisted, add three more properties to the Settings.settings file, and create a new ConfigurableWindowSettings object that knows how to get and set those values.

How to use it

It is easy to use the ConfigurableWindow class.  Here is a step-by-step explanation of how the demo application (available for download at the end of this post) was put together.  This walkthrough assumes that you already have a WPF project set up and you’ve included the source files for the ConfigurableWindow and ConfigurableWindowSettings classes.

First, create a new Window in your WPF project.  In this case, I named it DemoWindow.

Change DemoWindow so that it derives from ConfigurableWindow.  Note: you need to do this both in the code and XAML file.  Here is how you do it in the XAML:

Configurable Window (step 1)

Now that DemoWindow derives from ConfigurableWindow you need to override the CreateSettings method, and return an IConfigurableWindowSettings object.  Here is that method:

Configurable Window (step 2)

At this point, if you compile the project you will receive an error telling you that the DemoWindowConfigSettings class does not exist.  To remedy this situation, add a nested class in DemoWindow as seen below:

Configurable Window (step 3)

There are several things to notice about that class.  First, it derives from ConfigurableWindowSettings, which is a class that knows how to load and save window settings across runs of an application.  We pass into the base constructor five pieces of information: the backing store for all persisted property settings, and four property names.  Those property names correspond to settings that we will soon add to our application’s Settings.settings file.   Also, the DemoWindowConfigSettings class hooks the DemoWindow’s Closed event and sets the IsFirstRun setting to false.  This is necessary because it enables ConfigurableWindow to know if the persisted window location value is a value saved from a previous run or not.

Lastly, we need to add some settings into the project’s Settings.settings file.  We need to add four items, as seen below:

Configurable Window (step 4)

If you add more windows that derive from ConfigurableWindow, you only need to add the last three properties again with new names.  The IsFirstRun setting only needs to exist once since it applies to the entire application, not a specific window in the application.

Word of warning

If you run the application in debug mode (F5) you will be using a different config file than if you run without a debugger attached (Ctrl + F5).  This is the way things work in Visual Studio, so don’t be surprised if you stumble across this.

Get the code

Download the demo project here: Configurable Window Demo  (The source code was updated on 12/28/07).  Be sure to change the file extension from .DOC to .ZIP and then decompress the file.  Note, this project was built in Visual Studio 2008, so you will have to copy the source files into a new project if you are using VS2005.

Mole is now legit!

December 21, 2007

After clobbering the web with mountains of articles, blog posts, and comments about Mole, we decided that Mole needs a home.  We bought it a domain name, so that from now on whenever you need to find your latest Mole fix, just go here:

Right now that URL just gets forwarded over to the main Mole page on my blog.  Over time we hope to build a little Web site for Mole, and will eventually have the URL point there instead.

For some reason, Mole seems to be a “legitimate” project now that it has its very own URL.  Kind of silly… 

If you want to contact Team Mole with any questions/problems/suggestions about Mole, please send them to

Have a great holiday!

WPF vs. ASP.NET – An Architect’s Perspective

December 20, 2007

Karl Shifflett recently published a fabulous blog post explaining why he decided to use WPF instead of ASP.NET for his company’s large software product.  It is very down to earth and unbiased.  He obviously put a lot of thought into this, so I highly recommend checking it out.  Here’s the link:

WPF Podcast Player

December 19, 2007

This post shows a simple WPF application that plays podcasts.  The podcast information comes from RSS feeds.  The user has rudimentary control over a podcast, such as pausing and resuming it, adjusting the volume, and muting the podcast player.  Almost the entire application is in XAML.

In a previous post on my other blog, I showed how to create a very basic podcast player using Silverlight 2.0.  After finishing that project, I wanted to come back to WPF and build a better podcast player.  It was such a relief to return to the feature-rich world of WPF, after living a Spartan existence over in Silverlight land.

Here is what my WPF Podcast Player looks like:

WPF Podcast Player (screenshot)

As you can see, the application definitely does not provide a luxurious experience; it is pretty bare bones.  But it does offer the fundamental things need to start, pause, resume, and stop a podcast.  The only part of the application that required me to write code is pausing and resuming a podcast, since you have to call the Pause and Play methods on MediaElement.  You cannot call those methods from XAML.  In addition, a simple value converter class exists to detect if a podcast is an MP4 file, so that we do not show it (MediaElement does not seem to support that format).

All of the podcast RSS feeds are hard-coded into the ComboBox on top of the UI.  The selected item in the ComboBox is used to get the data source from which all podcasts are retrieved.  Here is how that works:

WPF Podcatcher (data sources)

Since we are binding to an RSS feed, which is an XML document, we can use XPath to pull out the values displayed in each ListBoxItem.  Here is the template used to display a podcast in the ListBox:

WPF Podcast Player (podcast template)

The remainder of the UI is just a bunch of controls which provide the user with a means of consuming and adjusting podcasts.  Here is the XAML for most of the UI:

WPF Podcast Player (controls)

Download the Visual Studio 2008 project here: WPF Podcatcher for VS2008

Download the Visual Studio 2005 project here: WPF Podcatcher for VS2005

Be sure to change the file extension from .DOC to .ZIP and then decompress the file.

Mole for Visual Studio

December 15, 2007

There have been many iterations of the Mole visualizer.  The latest and greatest release is not confined to WPF applications, it works with any application!!  Karl Shifflett and Andrew Smith (of Infragistics) have really hit the ball out of the park.  I helped out with testing, editing the article, and providing feedback.  I’ve been too busy learning Silverlight 1.1 to keep up with their amazing pace.  Great work guys!

Read the article and get the latest Mole for Visual Studio here:


(Note: I cross-posted this  blog entry between this blog and my new blog.  Normally I would not do this, but I really want to help spread the word about Mole for Visual Studio.  It’s such an awesome tool!)

The .NET world is now a better place

December 14, 2007

When I worked in the Infragistics WinForms development lab, I had the privilege of working with Andrew Smith.  If such a thing as a “guru” exists, Andrew is it.  His mastery of .NET programming is the best I have ever seen.  I don’t give compliments of that magnitude too often, but he deserves it.  Heck, as soon as he got involved with the Mole project, some of the really nasty bugs immediately disappeared and the performance improved drastically.  Abra-ca-dabra!

Fortunately, he has decided to share some of his programming thoughts with the rest of the world.  Yahoo!!  He recently started a blog here:

Thanks Andrew!

Meet my alter ego

December 13, 2007

This post is for my loyal readers out there.  In case you are looking for some extra blog posts by Yours Truly, you’re in luck.  Now that I work at Infragistics, I have a blog on their blog site as well.  My new blog is not devoted to WPF, in fact, I intend on posting all of my WPF content here.  The new blog will contain the type of posts that I never felt I should write about on a blog called “Josh Smith on WPF”.  

My new blog will be about all of the cool technologies that I research and use for my new job.  It should be a lot of fun, so why not stop on by once in a while to see what the non-WPF Josh is thinking about?  If you want to check it out, here are the links:


RSS 2.0:


See you there!

My first experience with Silverlight 2.0

December 13, 2007

I have spent the past couple of days checking out Silverlight 2.0.  I have much to say about my findings thus far, but in general, I am both shocked and pleasantly surprised.  Since Silverlight 2.0 is an alpha, there is no point in being too critical of it just yet.  According to Scott Guthrie the next RTM release, called Silverlight 2.0, will be much more feature-rich than the current alpha.

I expected Silverlight 2.0 to be an enormous, complex, sophisticated platform rivaling the technical splendor known as WPF.  I mean, it used to be called WPF/E , right? Boy was I wrong!  I just kept saying to myself, “I can’t believe Silverlight does not have that either!”  At first, it felt like I was trying to play a piano that had all of its white keys removed, and I could only use the black keys to make music.

Here is a brief list of some things in WPF that we know and love but are currently missing from SL 2.0:

  • Standard controls; like Button, TextBox, ListBox, CheckBox, etc.
  • Layout panels
  • Data binding
  • Templates
  • Styles
  • Commands
  • Routed events
  • A vast number of events on elements seen in WPF
  • A resource system based on merged resource dictionaries
  • Visual and logical trees (no programmatic construct represents them, at least)
  • Did I mention that there’s no Button???

Once I got past all those missing necessities, I found that what does currently exist is actually very cool.  If Microsoft delivers all that Guthrie promised in his blog post (which does not include everything in the list I provided above), SL 2.0 should be an excellent platform. 

I must admit, though, I really miss routed events.  Now that I think about events as tunneling and bubbling, working with normal CLR events really stinks.  It feels so primitive.  However, I might have found something that indicates Microsoft intends on adding routed events into SL 2.0 (even though Guthrie did not mention this in his post).  The EventTrigger class exposes a RoutedEvent property, just like in WPF.  It is possible that they named SL’s EventTrigger’s property “RoutedEvent” to ensure that the Silverlight XAML compiles in WPF, but perhaps they actually intend on implementing routed events in the future.  Think about it, what sense would it make to have a property called RoutedEvent if routed events do not exist in SL?

I tried watching some of the video tutorials on that go over the basics, but most of them were so dumbed-down that I felt like I was in a Special Ed class.  I have found the Quick Start tutorials to be very helpful and insightful for a newbie, such as myself.

For my first SL 2.0 project I decided to build a very simple ListBox control.  Please keep in mind that this is the first Silverlight project I have ever written, so don’t expect anything too cool.  After creating this ListBox I found out that the Silverlight SDK comes with the source code for a ListBox control.  I checked out the SDK control, and it is definitely better than mine is, but at least mine allows you to navigate the items with your keyboard.  Ahha!  Take that, Microsoft!!  😉

Below is a screenshot of my AgListBox control in action, with some text above it explaining which item is selected (in case you couldn’t already tell…):

AgListBox in action

Here is My First Silverlight Project.   Be sure to change the file extension from .DOC to .ZIP and then decompress the file.  If you need to install the Silverlight runtime and tools, check out the list of requirements and links here.

Mole II has been enhanced

December 11, 2007

Karl Shifflett decided that Mole II was not good enough, so he added in a feature which allows you to see non-public fields of the object you are inspecting.  Now you can see properties and fields, which makes the debugging process even more rapid because the true state of your objects can be seen with ease.  After we reviewed the new feature, Karl blogged about it and wrote an article on CodeProject.  Check out his updates here:

As of this writing, this new feature does not display the private fields of an object’s ancestor types.  It only displays the fields found in the object’s most derived partial.  I think that needs to be addressed before it is truly “done,” but so far it’s a great start.  Nice work, Karl!