I love the M-V-VM pattern for Silverlight and WPF applications.  It’s beautiful and works very well, but sometimes it is too verbose, particularly in the ViewModels’ INotifyPropertyChanged implementations.  I find that I spend too much time on the repetitive plumbing tasks that could otherwise be spent programming the actual application logic.

There are many tools and frameworks out there to speed up and simplify MVVM (Caliburn, MVVM Light, WAF, etc.), but I just discovered a very simple tool that goes a long way toward making MVVM more useable. 

It’s called NotifyPropertyWeaver and it solves the problem ...

UPDATE May 4, 2011: It was brought to my attention that there was a typo in my code below, but it is now fixed.

I sometimes find it necessary to walk the visual tree of controls in Silverlight (or WPF) at run-time.  The VisualTreeHelper class provides some nice functionality for doing this.  However, using the VisualTreeHelper can sometimes require a little too much code, especially when I want to search the visual tree recursively. 

For this reason I created some simple extension methods to do the recursing for me.  Let’s cut right to the chase.  Here’s the code:

I got some positive feedback on my recent post about binding a TextBlock’s tooltip to its own text property, so I decided to post this related follow-up…

Allowing your users to navigate your forms with the keyboard is a very important usability feature that is often overlooked.  In Silverlight, this is accomplished by setting IsTabStop to True on any controls you want to participate in keyboard navigation.  When the user hits the tab key, focus will cycle through all the controls where IsTabStop is True, one at a time.  Any controls where IsTabStop is false will be skipped....

Those that have been programming in WPF for a while probably already know about defining styles based on other styles.  With the release of version 3, this feature made the jump over to Silverlight as well.  Even though this is old news, as Silverlight is now on version 4, I’ve found that this feature is still little-know, and it’s so useful, I thought it deserved a post.  In the post, I’ll go over the basics of how to use this feature for anyone to whom the feature is new.

Why Use BasedOn

Using BasedOn to define a style allows ...

Most of the time it’s not a big deal knowing what the binding source is. However when you have to go searching for that source with calls like RelativeSource then you’re not always sure of what you’re getting, if anything. I’ve found using a simple non converter can help a great deal. Let’s say you have a binding in xaml that looks something like this.

In part 1 I talked about our strongly typed GenericAttachedProperty<A> class that allows you to quickly attach any object or class to a UI element. This works great as long as you only need to store one int and/or one string and/or one TMyBigClass on the same element. To be able to attach more than one of a particular type to the same UI element we need to update our GenericAttachedProperty<A> class. The problem is that our GenericAttachedProperty<A> class uses the same dependency property name “Value” for all generic types.

public  class GenericAttachedProperty<T>

    {

  public  static  readonly DependencyProperty ValueProperty =...

Custom attached properties are a great thing to have and use in a project. If you’re unfamiliar with attached properties or custom attached properties, a good overview can be found here. The basic pattern is easy to implement and is generically the same as shown below.

public  static  readonly DependencyProperty IsBubbleSourceProperty = DependencyProperty.RegisterAttached(

  "IsBubbleSource",

  typeof(Boolean),

  typeof(AquariumObject),

  null

);

public  static  void SetIsBubbleSource(UIElement element, Boolean  value)

{

  element.SetValue(IsBubbleSourceProperty,  value);

}

public  static Boolean GetIsBubbleSource(UIElement element)

{

  return (Boolean)element.GetValue(IsBubbleSourceProperty);

}