I recently published an article on CodeProject that reviews a WPF graphing application.  It turns out that my original circular dependency detection algorithm did not detect all circles in certain scenarios.  I completely rewrote that algorithm, so that it now properly detects all circles in any object graph.

I also modified the way that the node connectors move, so that it feels more responsive and elastic.  The app is much better now, and the article has been updated to reflect these changes (including a new source code download).  If you want to check it out, here’s the link:

http://www.codeproject.com/KB/WPF/WpfGraphVisualization.aspx

I spent the weekend having a blast writing a WPF app that displays an interactive object graph, and detects/highlights circular dependencies. It was so much fun, that I decided to publish an article about it on CodeProject.

Here’s a screenshot of the app:

The app uses Charles Petzold’s ArrowLine element, PropertyObserver and ObservableObject from my MVVM Foundation library, DragCanvas from WPF.JoshSmith, and ContentControl3D from Thriple.

If you want to check it out, here’s the article:

http://www.codeproject.com/KB/WPF/WpfGraphVisualization.aspx

Enjoy!

When working on large WPF or Silverlight applications, you can end up with a lot of XAML files.  If you are using the MVVM pattern, many of those XAML files contain a View whose DataContext is expected to be set to a certain type of ViewModel object.  It can sometimes become difficult to remember which Views expects which ViewModel as their DataContext.  One very simple and lightweight way to help you and your team remember a View’s expected DataContext type is to leave an XML comment at the top of the XAML file.  This incredibly simple and obvious technique can be a HUGE timesaver later on down the road!

I highly suggest that you get into the habit of doing this, if you haven’t done so already.  You will thank yourself many times later…

This morning I decided to build a little WPF dialog window that would show the visual tree of some UI, and provide visual indicators over that UI when you select one of its elements.  This was just a fun exercise.  If you want to have a serious element tree viewer, then be sure to use Snoop instead.  This quick post just shows the result of my morning fun.

Here’s the resulting dialog window in action:

Notice that a ContentPresenter is selected, which contains an image of a ninja.  In the UI being analyzed, you’ll see that the ContentPresenter is decorated with a light green box:

The “Snooper” dialog window contains a TreeView that renders the visual tree of the other UI.  That TreeView is declared as:

It is bound to a hierarchy of VisualElement objects.  VisualElement is a class that I made to represent an element and its child elements.  The important part of that class is seen below:

Notice that when a VisualElement is selected, it puts a SelectionAdorner into the adorner layer of its associated UIElement.  SelectionAdorner is a class I made that just renders a rectangle around some element.  It is seen below:

You can download the demo project here.  NOTE: Be sure to change the file extension from .DOC to .ZIP and then decompress.  WPF is fun!

I just published an article about a technique I use to streamline and simplify the way that ViewModels are created in an MVVM app.  I’m not saying that this is the “right” way to do things, but simply something I find useful.  Enjoy!

http://www.codeproject.com/KB/WPF/FromRussiaWithLove.aspx

In case you ever need to prevent the user from selecting a tab in a WPF TabControl, here’s one way to do it…

The SelectedContent of the TabControl hasn’t changed at the time that the ItemsSource’s default collection view raises its CurrentChanging event.  If you decide to lock the user into the selected tab, simply set the TabControl’s SelectedIndex back to the index of the SelectedContent.  No fuss, no muss…

I set aside some time today to add some goodness, and remove some badness, from my MVVM Foundation library on CodePlex.  Special thanks go to Matt Heffron for his great work on making the Messenger class much safer and user-friendly.  Here is a listing of the changes:

• Added safety checks and helpful error messages in Messenger for callback registration and message broadcasting. Unit tests were added to verify this behavior.
• Ensured that Messenger notifies colleagues of a message in the order they registered for that message. Unit tests were added to verify this behavior.
• Fixed an issue in an ObservableObject unit test where it failed in a Release build.

It’s exciting for me to see the improvements and ideas suggested by people using MVVM Foundation!  I appreciate the time people have contributed toward making the library better.  I hope there are no hard feelings when I reject a proposed feature.  :)

You can get the latest source code here: http://mvvmfoundation.codeplex.com/SourceControl/ListDownloadableCommits.aspx

I just added a demo application to the MVVM Foundation project on CodePlex.  It is contrived, but shows how to use ViewModelBase, RelayCommand, PropertyObserver, and Messenger.  You can download the latest source code here.

Today I published a new CodePlex project, called MVVM Foundation.  It is a  library of my favorite classes to use in MVVM applications.  Right now, it only contains classes suited for WPF applications, but eventually I will get around to adding in a Silverlight version, too.  If you would like to check it out, here’s the link:

http://mvvmfoundation.codeplex.com/

EDIT: Shortly after publishing this blog post, I received some excellent feedback on it, and updated the PropertyObserver class to implement IWeakEventListener.  Special thanks go to Huseyin Tufekcilerli for posting an IWeakEventListener implementation, which got me 90% of the way toward a better solution. This blog post and its source code download have been updated to reflect this improvement.

When working with objects that implement INotifyPropertyChanged, as most ViewModel objects tend to do, it often becomes necessary to attach a handler to their PropertyChanged event.  Your code can quickly accumulate many event handling methods full of conditional statements that check if e.PropertyName equals some hard-coded string value.  This leads to messy, brittle code that becomes difficult to maintain as the mess gets larger.

To combat this evil, I decided to mechanize as much of this as possible.  I created a generic class called PropertyObserver<TPropertySource> which monitors the PropertyChanged event of an object, and executes whatever callback methods you have registered for when certain properties have changed.  In addition, that class will verify that every property name you register with it is a real, public property on the object being observed, because the way that you provide the property  name is checked by the compiler (you pass it a lambda expression that references the property).  If a property name changes, but you forgot to update your code that registers the property with PropertyObserver, you will get a compiler error next time you try to build your solution.

Here are the two methods of interest:

Here is a simple example, from the source code download, that shows how to use PropertyObserver:

You can download the source code here.  Note: Change the file extension from .DOC to .ZIP and then decompress it.

I just published an article to CodeProject called ‘Displaying a Data Matrix in WPF‘.  This one was definitely a labor of love.

Enjoy!

Rudi Grobler recently posted an article called ‘Classic Jukebox‘ that shows how to build a jukebox application using custom hardware.  It’s a very cool idea, and his article is well worth reading.

This article reminds me of a problem that I was discussing with someone at work the other day, and have been thinking about since.  What are the best practices for designing an app, let’s say the Jukebox app, such that it can accomodate multiple form factors?  Suppose you wanted this app to be controlled by a custom input device, or a regular mouse + keyboard, or on a multi-touch device like Microsoft Surface, or an HP TouchSmart running Windows 7. 

Each form factor would bring along new, and potentially unique, interaction possibilities: Surface allows for multi-finger gestures, while a traditional keyboard allows for things like shortcut keys, etc.  How should the MVVM design be used/augmented to make the input processing device-specific, without convulting the core application logic (play next song, pause, lower volume, etc)?  Should there be an intermediary layer  between View and ViewModel, which is perhaps an InteractionModel, to which the device-specific View is bound?   This topic is something that I’m very interested in, so expect to see some more posts on it in the near future.

Food for thought…

I started working at IdentityMine a few weeks ago, and have been exposed to several very interesting projects made by some very smart people.  One project that I think has a lot of potential was created by Andrew Whiddett.  He created a library that adds in-depth routed event support in Silverlight 3.  If you are working with Silverlight, I highly suggest you check this exciting project out!  I’m very interested in seeing where this goes…

http://sl3routedevents.codeplex.com/

If you have any feedback on that library, please leave it on the project’s Discussions board.  Enjoy!

Introduction

When working with the Model-View-ViewModel (MVVM) pattern, the data shown in a View is almost always transferred to it via data binding.  Changes made to properties on a ViewModel object immediately propagate to the binding targets in the View.  This is normally a good thing.  Sometimes, however, the immediacy of the propagation can be a problem.

Why would you want a new property value to not immediately show up in the UI?  Well, suppose you want to display an animated transition between the old value and the new value.  If the new value immediately shows up in the View, you won’t have a chance to animate “out” the old value before animating “in” the new value.   For example, suppose the property’s value is a page of data items to show in a list.  If we want to fade away the first page of items before fading in the new page of items, we need to start the fade-away animations before the new page of items is displayed.

This is the type of problem that the Visual State Manager (VSM) solves.  Since the VSM is not yet part of WPF proper (it won’t be until .NET 4.0), we cannot make use of it yet in production applications.  Also, the VSM is designed to be used inside of custom controls, so it is not exactly equivalent to what we are going to explore below.

The AnimatedTransition Class

I faced this exact problem many times while working on WPF and Silverlight applications.  After experimenting with several approaches to coordinating property changes with animated transitions, I started to understand the core problem more clearly.   Yesterday I listened to this incredible rendition of the Scherzo from Mendelssohn’s “A Midsummer’s Night Dream” and was hit by a flash of inspiration.  I realized a way to create a simple, type-safe, reusable way of having a ViewModel and View work together to create animated transitions between two property values.  The AnimatedTransition class was born!

An instance of AnimatedTransition can be embedded in any ViewModel class.  The View(s) that need to perform transitions must access the AnimatedTransition object and hook one or more of its events in order to know when transitions should start.

The Demo App

In the demo app, which is available at the bottom of this post, there is an ItemsControl that displays four Hello Kitty images per “page,” as seen below…

When the user navigates to a different page, via the circles below, the old kitties fade away and then the new ones fade in.

We are not going to examine all of the classes involved in making this little app work.  If you want to get a high-level understanding of the ViewModel classes, click on this class diagram to view it at full size:

The current page of kitties to show in the ItemsControl is contained in SelectedPage property of KittyKatTerraceViewModel.  Since we need to have a transition between the two values of that property, we use an AnimatedTransition to enable that.  Here is how KittyKatTerraceViewModel uses and exposes an AnimatedTransition:

When the user clicks on a little circle beneath the ItemsControl to select a page, this method in the PageOfKittyKatsViewModel class executes:

All of the relevant logic in the KittyKatTerraceView control’s code-behind is listed below.  This shows how a View can consume and interact with an AnimatedTransition object.

It’s important to note that you must attach a handler to the Completed event of the Storyboard that fades away the old items.  When the event is raised, the AnimatedTransition must be told to finish transitioning to the new value, and actually apply the value.  That is accomplished by calling the Finish() method.  Once the new value has been applied, the AfterApplyNewValue event is raised, at which time you can fade in the new items.

You can download the source code here.  Note: Be sure to change the file extension from .DOC to .ZIP and then decompress it.

I am very proud, and excited, to announce that I will soon join IdentityMine as a Senior UX Developer!  IdentityMine specializes in designing and developing excellent user experiences via technologies like WPF, Silverlight, and Microsoft Surface.   The firm is very well-known and respected in the Microsoft Client App Dev space, so I’m thrilled to join their ranks and help build awesome applications.

Despite my excitement over this new opportunity, I must admit that I will miss working at Infragistics.  I am leaving behind a lot of talented, friendly, energetic people there, and wish the best for all of them.   Sometimes in life, you just “gotta do what ya gotta do.”  This is one of those times for me.

I have a one-way ticket to Seattle for tonight.  See you there…

This blog post shows a prototype implementation of the Mediator design pattern, intended to be used in WPF and, possibly, Silverlight applications.  The Mediator class can be used to provide loosely-coupled message-based communication between various entities, such as ViewModel objects.  The prototype was inspired by this thread on the WPF Disciples group, and particularly by conversations I had with Marlon Grech.  I am posting this prototype on my blog, in hopes of receiving suggestions and new ideas on how to improve the design.
The code reviewed in this blog post works, but is not complete or intended to be used in production applications.

Creating a class that allows various objects to send messages to each other is trivial.  It becomes more challenging when you try to create a reusable class like that which does not leak memory.  Since the Mediator object can live indefinitely, but the objects registered to receive messages might have a shorter lifespan, this could easily become a hotspot for memory leaks to occur.  In an ideal world, any object that registers itself to receive messages should unregister itself when it no longer needs to receive messages.  However, in practice, it’s not always easy to know when an object should unregister itself.  The design of the Mediator class needs to take this into consideration.

Let’s take a quick look at how this Mediator class might be used.  Here’s some code showing how an object registers itself to receive a certain message…

Notice that registering for a message requires you to pass in two parameters.  The first parameter is a unique identifier for that message, in this case a string exposed by the MediatorMessages class.  The second parameter is a delegate of type Action<object>.  In the example above I use a lambda expression to create the delegate, but you could just as easily create a new Action<object> instance, if you’d prefer.

Here is an example of an object sending its colleagues a message:

So far, so good, so it seems.  However, there is a problem.  A delegate, such as Action<object>, stores a reference to the object on which the target method should be invoked.  When you pass that delegate to the Mediator, it stores the delegate in a collection, for later use. If you never remove the delegate from the Mediator, via unregistering (which is something I have yet to implement in the prototype), the registered object will never be eligible for garbage collection since there will be a hard reference to it.  Hence, the memory leak issue I mentioned earlier.

My first thought was to store a reference to the Action<object> in a WeakReference.  Since the Garbage Collector will throw away objects that are referenced only by WeakReference objects, it would seem that this would do the trick.  Unfortunately, it’s not that simple.  The problem with that approach is that the GC will throw away the Action<object> instance because it is only being referenced by a WeakReference!

Marlon came up with a great idea, which borrows Greg Schechter’s idea of subclassing WeakReference to make a “weak delegate.”  This is essentially a delegate that uses a WeakReference to store a reference to the target object, instead of using a normal object reference, as normal delegates do.  The drawback to Marlon’s great idea is that it relies on the use of reflection to invoke the target method on the colleague.  This means that it will have a performance decrease, and won’t run in partial trust.

I took Marlon’s idea, and refined it so that it does not require the use of reflection (at least, not directly).  My implementation uses a class I called WeakAction, which looks like this:

The collection used by Mediator, which maps a Message to a list of Action<object>, is called MessageToActionsMap.  That class uses the WeakAction type, as seen below:

As you can see in the following Mediator method, this implementation detail does not bubble up into the public-facing API:

You can download the prototype source code and demo app here: Mediator Prototype and Demo .  NOTE: Be sure to change the file extension from .DOC to .ZIP, and then decompress it.

If you have any suggested improvements, bugs, etc. please don’t hesitate to let me know.

An article by Joel Eden, a colleague of mine at Infragistics, was recently published in Dr. Dobb’s. The article is called ‘Designing for Multi-Touch, Multi-User and Gesture-Based Systems‘.   It touches on the very interesting topic of how to design good user experiences for the next generation of multi-touch systems, such as Microsoft Surface applications.  This is something that I have been wondering about, so I was thrilled to discover this article.  It is very well written and explains the subject matter in a clear, understandable way.  For example, here’s an excerpt that I find very thought provoking…

If gestures are already so much a part of our cognitive processing then in some ways, the growing excitement around gesture-based systems is a sign that software systems are finally catching up to how we already think and behave, rather than really representing an innovative way of interacting with information.

You can read the article here: http://www.ddj.com/architect/216402697

Jaime Rodriguez and Karl Shifflett recently announced that they will be traveling the world to teach how to use WPF to create Line of Business applications…for free!  Those guys really know WPF and what it takes to build business apps, so I’m sure their training sessions will be packed with useful, important, interesting information.  You can read more about this exciting opportunity on Jaime’s blog:

Announcing the “WPF for LOB” Training Tour

Considering that their previous training sessions were sold out, if you are interested in attending, I highly suggest you register asap.

Great news arrived today.  Microsoft has given me the MVP title, once again!   This my third year in a row as an MVP, and hopefully not my last.

I must say, though, that receiving this notification on April Fool’s Day is slightly unnerving…

Due to user feedback, I created a sample that shows how you can use ContentControl3D to host content in the cells of the Infragistics XamDataGrid.  I really like this idea, and think it has a lot of potential in many different kinds of applications.  It allows you to compress a lot of information into one column in the data grid.  The following screenshot from the demo app shows two records: one is showing the front side of a ContentControl3D, the other is showing the back side (the edit form)…

You can download this demo app from the Releases page of the Thriple project.  The demo app requires that you have the Infragistics NetAdvantage for WPF product installed (trial version or regular version) in order to run it.