Yet another blog about WPF, Surface, SL, MVVM, NUI....

The title may not be clear but I am talking about the entities that you extends on the client side using the fact that they are partial class. You may think as I was that if you add properties in them with backing store field, the properties will get initialed nicely : this is not the case and the property will always use the default value for the property type.

In this post we’ll discover how to perform our goal : create a property with the correct default value.

Take for example a Task entity in which you want to add a property IsVisible to tells the View if it should display it or not. By default, the Task should be visible. You will end up with this resulting code :

public partial class Task
{
//Default framework value for boolean is Falsek
private bool _isVisible = true;
public bool IsVisible
{
get
{
return _isVisible;
}
set
{
_isVisible = value;
}
}
}

But it won’t work and every loaded entity will have the IsVisible property to the default value which is Fase. Notice that I used the “loaded” verb and not “create” because the entity created use the correct value.

So why is it not working ?

In fact this is quite easy : when you load the entities, they are not created the usual way but de-serialized from the stream sended by the server so since the property is only on the client side, it wont be initialized with your value but with the default one. When you create entities, like the whole object is present on the client side and no de-serialisation is done, it will work as usual.

But RIA Services do not let us alone, the best practice is to initialize the default value of this kind in an override of the OnLoaded method. The final and working code should then be(take care to read the edit below after):

public partial class Task
{
protected override void OnLoaded(bool isInitialLoad)
{
base.OnLoaded(isInitialLoad);
IsVisible = true;
}
//Default framework value for boolean is Falsek
private bool _isVisible = true;
public bool IsVisible
{
get
{
return _isVisible;
}
set
{
_isVisible = value;
}
}
}

Hope this will save you the time to investigate I spend on this…

EDIT: In fact the entities are reloaded each time you submit changes and there is currently a bug (which will be fixed in the SP1  - as pointed out by Jeff in the comments) which will reset the value of your property to the default value even if it has been changed since.. But I have found a quite easy work around, by using two differents variables and knowing that RIA will simply ignore internal properties :

public partial class Task
{
protected override void OnLoaded(bool isInitialLoad)
{
base.OnLoaded(isInitialLoad);
//only for the initial load
if (isInitialLoad)
{
IsVisibleFix = true;
}
}
//Default framework value for boolean is Falsek
private bool _isVisible = true;
public bool _isVisible
{
//NO setter so RIA can't update the value
get { return _isVisible; }
}
//Internal so RIA ignore it and don't set the value
internal bool IsVisibleFix {
set { _isVisible = value; RaisePropertyChanged("DeleteVisibility"); }
}
}

You can read more on this forum post too : http://forums.silverlight.net/forums/t/203750.aspx

When building a (multi)touch application you may need one nice feature : translate hand-written text to real words. This open a whole new world full of possibilities like starting some actions when keywords are recognized or simply allow the users to write some text for later use. 

In this post we'll see all the step to create an hand writing to text control and how to tune it.

You are surely, as I am, creating a lot of units tests in your WPF applications.

Some of the tests may use statics or dynamics resources declared in your application and when you launch the tests, all you get is an XamlParseException exception thrown.

System.Windows.Markup.XamlParseException: 'Provide value on 'System.Windows.StaticResourceExtension' threw an exception.' Line number '11' and line position '83'.
---> System.Exception: Cannot find resource named 'myStaticResource'. Resource names are case sensitive.

The tip to make them work is quite simple to use. What is actually happening ? : the created control is looking for the resource via the classic russian puppets system and does not find the application because the tests does not create it. And the application is exactly where you have declared the needed ressources. So all we've got to do is to create the application and initialize it before running the tests.

Also we called the InitializeComponent() methods to make sure the application is initialized. It seems that this last part is only necessary if the resources are from the same assembly than the application.

So just add this method to your tests classes :

/// <summary>
///Use ClassInitialize to run code before running the first test in the class
/// </summary>
/// <param name="testContext">The test context.</param>
[ClassInitialize()]
public static void MyClassInitialize(TestContext testContext)
{
  //Create the application for resources.
  if (System.Windows.Application.Current == null)
  {
    App application = new App();
    application.InitializeComponent();
  }
}

The App.xaml content is below:

<Application x:Class="MyAssembly.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:myLib="clr-namespace:MyAssembly.ViewModels"
	StartupUri="Views\MainWindow.xaml">
 
  <Application.Resources>
    <ResourceDictionary>
      <myLib:ViewModelLocator x:Key="myStaticResource" />
    </ResourceDictionary>
 
  </Application.Resources>
</Application>

Here we are !

Today another example of the powerful ramora pattern : execute a RoutedCommand on an Control when you click on a button outside of the aimed control scope.

When is it useful ? : for example when you use the infragistics grid (xamdatagrid) and you want to execute the command which remove the selected row from a button outside of the grid. You then have to exectue the DeleteSelectedDataRecords command on the grid from a button which is outside of the scope of the grid ... then this behavior is useful !

Our implementation will also show how we can apply the "Weak Events pattern" with the dependency property trick (attached property / ramora pattern).

And of course this example can be adapted to subscribe on any event you wants and not only the click of a button.

The behavior itself

Our behavior will listen to the click button, and the handling of the click event will execute the routed command on the target element.

public class ExecuteCommandOnControl : DependencyObject
{
  #region Command
 
  /// <summary>
  /// Command Attached Dependency Property
  /// </summary>
  public static readonly DependencyProperty RoutedCommandProperty =
    DependencyProperty.RegisterAttached("RoutedCommand", typeof(RoutedCommand)
	     , typeof(ExecuteCommandOnControl));
 
  /// <summary>
  /// Gets the Command property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static RoutedCommand GetRoutedCommand(DependencyObject d)
  {
    return (RoutedCommand)d.GetValue(RoutedCommandProperty);
  }
 
  /// <summary>
  /// Sets the Command property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static void SetRoutedCommand(DependencyObject d, RoutedCommand value)
  {
    d.SetValue(RoutedCommandProperty, value);
  }
 
  #endregion
 
  #region IInputElement
  /// <summary>
  /// IInputElement Attached Dependency Property
  /// </summary>
  public static readonly DependencyProperty TargetProperty =
    DependencyProperty.RegisterAttached("Target", typeof(IInputElement), 
	   typeof(ExecuteCommandOnControl),
      new FrameworkPropertyMetadata(null,
        new PropertyChangedCallback(OnTargetChanged)));
 
  /// <summary>
  /// Gets the IInputElement property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static IInputElement GetTarget(DependencyObject d)
  {
    return (IInputElement)d.GetValue(TargetProperty);
  }
 
  /// <summary>
  /// Sets the IInputElement property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static void SetTarget(DependencyObject d, IInputElement value)
  {
    d.SetValue(TargetProperty, value);
  }
 
  /// <summary>
  /// Handles changes to the IInputElement property.
  /// </summary>
  private static void OnTargetChanged(DependencyObject d, 
     DependencyPropertyChangedEventArgs e)
  {
    Button button = d as Button;
 
    if (button != null)
    {
      ButtonClickEventManager.AddListener(button, _customEventListener);
 
    } else
    {
      throw 
	  new ArgumentException("This behavior can only be installed on non-null Button !");
    }
  }
 
  #endregion
 
  private static CustomEventListener _customEventListener = new CustomEventListener();
 
}

WeakEvents

So what is the class CustomEventListener ? This is the object which will handle the click on the button. This class implements the interface IWeakEventListener which is a necessary things to use the Weak event pattern.

We will then not subscribe the click event with the usual way ( using the operator +=) but by calling a WeakEventManager of our own : ButtonClickEventManager.

This manager will then keep a weak reference of our listener and the button on which we operate will then be free to be garbage collected. Otherwise, every button on which we subscribe would be keeped in the memory because each one would be connected to our behavior...

Here is the CustomEventListener class :

public class CustomEventListener : IWeakEventListener
{
  #region IWeakEventListener Members
  public bool ReceiveWeakEvent(Type managerType, object sender, EventArgs e)
  {
    if (managerType == typeof(ButtonClickEventManager))
    {
      var target = 
	  ExecuteCommandOnControl.GetTarget(sender as DependencyObject);
      var command = 
	  ExecuteCommandOnControl.GetRoutedCommand(sender as DependencyObject);
 
      if (target == null || command == null) return true;
 
      command.Execute(null, target);
      return true;
    } else
    {
      return false;
    }
  }
  #endregion
}

And here is our WeakEventMAnager :

public class ButtonClickEventManager : WeakEventManager
{
 
  public static void AddListener(Button source, 
       IWeakEventListener listener)
  {
    ButtonClickEventManager.
	   CurrentManager.ProtectedAddListener(source, listener);
  }
 
  public static void RemoveListener(Button source, 
       IWeakEventListener listener)
  {
    ButtonClickEventManager.
	   CurrentManager.ProtectedRemoveListener(source, listener);
  }
 
  protected override void StartListening(object source)
  {
    Button button = (Button)source;
    button.Click += this.OnButtonClick;
  }
 
  protected override void StopListening(object source)
  {
    Button button = (Button)source;
    button.Click -= this.OnButtonClick;
  }
 
  private void OnButtonClick(Object sender, RoutedEventArgs args)
  {
    base.DeliverEvent(sender, args);
  }
 
  private static ButtonClickEventManager CurrentManager
  {
    get
    {
      Type managerType = typeof(ButtonClickEventManager);
      ButtonClickEventManager manager = 
	  (ButtonClickEventManager)WeakEventManager.GetCurrentManager(managerType);
      if (manager == null)
      {
        manager = new ButtonClickEventManager();
        WeakEventManager.SetCurrentManager(managerType, manager);
      }
      return manager;
    }
  }
}

Example of use

Here a little example of how you can use it to launch the deleteSelected command of the infragistics datagrid from a button outside of the grid :

<Button Content="Delete selected"
  tools:ExecuteCommandOnControl.RoutedCommand="{x:Static igDP:DataPresenterCommands.DeleteSelectedDataRecords}"
  tools:ExecuteCommandOnControl.Target="{Binding ElementName=dataGrid}" />
<igDP:XamDataGrid Name="dataGrid" DataSource="{Binding Data}" />

Interesting readings

• Weak event pattern in WPF.
• Weak Eventing & Listening for .NET/Silverlight
• MSDN on the weak event pattern
• Understanding routed commands by Josh Smith

Today a fast and easy tip about shadows and performance.

In a project I have recently made, we've told the designer not to use BitmapEffects because they are performance killer. He so decided to create it's own shadows by duplicating each shape and make them looks like shadows(designer magic, voodoo things, etc...). I was then surprised to see that it kills performance too !


There is still the shaders effect which came with the 3.5 SP1 framework but they will be available only on vista or greater plateforms and their performance will depend of your graphic cards.

But we have an another ace in you deck : the system shadow which are quite fast even on software rendering!

Using it is quite easy :

1. Add the PresentationFramework.Aero reference to your project,
2. Add the following XML namespace : ”clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero”,
3. Use the SystemDropShadowChrome element available with this namespace !

But there is a drawback : you can only produce squared shadows. But you can still play with the CornerRadius property to create simily round shadows.

Here is a little example of XAML code:

<UniformGrid
    xmlns:shadows="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero"
    Columns="2">
  <shadows:SystemDropShadowChrome Margin="25">
    <ListBox>
      <ListBoxItem Content="One item" />
      <ListBoxItem Content="Another item" />
      <ListBoxItem Content="Another third item" />
    </ListBox>
  </shadows:SystemDropShadowChrome >
 
  <shadows:SystemDropShadowChrome Margin="25" CornerRadius="800" Width="100" Height="100">
    <Ellipse Stroke="Black" Fill="White" />
  </shadows:SystemDropShadowChrome>
</UniformGrid>

There is time when you have to copy each property of an object to one another. This is called mapping and it's very fastidious to do it by hand.

In this post we'll see how to create a method extension which do it for you in one line of code !

When can it be useful

Here is a non exhaustive list of usage you can find to this snippet:

• You want to reload the previous state of an object without changing it's instance : just clone it as a snapshot and copy back the properties when you want,
• You get's some Data Transfert Object coming from WCF/Web services and you want's to fill a specific object with this data,
• etc ...

I surely know this is not the most efficient way to solve these problems, but this is fast to use/understand and easy to implements.

Let's jump to the code !

What's inside ? Quite a few things actually ! There is two object, the source in which we take the data and the target in which we fill in these datas.

I use reflection to obtain every property of the source and then I check on the target if a property exist with the same name. If yes I fill it with the value of the property in the source object.

I also added a filter which is a list of Property name which will be ignored by the "copy process".

With a little more time you can also add a dictionnary which may map a property name in the source to an another property name in the target if the name are note exactly the same...

public static class PropetiesMapper{
	/// <summary>
    /// Copies all the properties of the "from" object to this object if they exists.
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    /// <param name="excludedProperties">Exclude these proeprties from the copy</param>
    public static void copyPropertiesFrom(this object to, object from, string[] excludedProperties)
    {
 
      Type targetType = to.GetType();
      Type sourceType = from.GetType();
 
      PropertyInfo[] sourceProps = sourceType.GetProperties();
      foreach (var propInfo in sourceProps)
      {
        //filter the properties
        if (excludedProperties != null
          && excludedProperties.Contains(propInfo.Name))
          continue;
 
        //Get the matching property from the target
        PropertyInfo toProp =
          (targetType == sourceType) ? propInfo : targetType.GetProperty(propInfo.Name);
 
        //If it exists and it's writeable
        if (toProp != null && toProp.CanWrite)
        {
          //Copty the value from the source to the target
          Object value = propInfo.GetValue(from, null);
          toProp.SetValue(to,value , null);
        }
      }
    }
 
    /// <summary>
    /// Copies all the properties of the "from" object to this object if they exists.
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    public static void copyPropertiesFrom(this object to, object from)
    {
      to.copyPropertiesFrom(from, null);
    }
 
    /// <summary>
    /// Copies all the properties of this object to the "to" object
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    public static void copyPropertiesTo(this object from, object to)
    {
      to.copyPropertiesFrom(from, null);
    }
 
    /// <summary>
    /// Copies all the properties of this object to the "to" object
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    /// <param name="excludedProperties">Exclude these proeprties from the copy</param>
    public static void copyPropertiesTo(this object from, object to, string[] excludedProperties)
    {
      to.copyPropertiesFrom(from, excludedProperties);
    }
  }

So, do you still want to put an "Hand made" label on your object's mapping ?

A more complex and complete tool

For those which wants something more powerful and complete : take a look at the automapper library on codeplex.

MVVM - Creating ViewModel is a serie of blogposts that talk in details about various ways to create a ViewModel to use it with the MVVM pattern.

You often do not create the business object used by the application which are created by another team and that these objects are not ready for binding.

So you must find a solution to create an object which will in fact be very similar of your business object BUT ready for binding. These posts describe the differents solutions you have in hand.


So far the following parts have been published:

1. Wrap your business object
2. Use XAML Power Toys
3. Create dynamic proxies
4. Use the object builder of CAB
5. Generate IL code (TO DO)

If you have other solution, don't forget to tell about in the comments !

Synopsis

The ribbon controls - introduced by office 2007 -are available for free on the Microsoft Office web site (French users should set the language to "english" to access the ressources). They can leverage the user's experience of your application and are pretty simple to use.

When I wanted to add them into one of my application I realized that it was broking the M-V-VM pattern.

In this post, we will see how to use the Ribbon, then what exactly is the issue and finally examine the solution I use as a work-around.

How to use the ribbon

This is very easy, here are the steps :

• Download the library on the web site (http://msdn.microsoft.com/fr-fr/office/aa973809.aspx),
• Add a reference to the dll in your project and dclare in the XAML this XML namespace : clr-namespace:Microsoft.Windows.Controls.Ribbon;assembly=RibbonControlsLibrary
• Then you are free to use the ribbon's controls.

A central part of the Ribbon library is the RibbonCommand. A RibbonCommand is a WPF command plus a lot of things related to how it's presented : a label, a description, an large image, a small image, etc.... Then every button, combobox, checkbox, ... used in the Ribbon use these infos to change the way they are presented. Here is a little example :

<Window x:Class="MVVMRibbon.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:r="clr-namespace:Microsoft.Windows.Controls.Ribbon;assembly=RibbonControlsLibrary"
    Title="MainWindow" Height="350" Width="525">
 
  <Window.Resources>
    <r:RibbonCommand x:Key="MyFirstCommand" LabelTitle="A command"
        LabelDescription="A command description"
        LargeImageSource="/MVVMRibbon;component/antoine64x64.jpg"
        SmallImageSource="/MVVMRibbon;component/antoine64x64.jpg"
        Executed="RibbonCommand_Executed" CanExecute="RibbonCommand_CanExecute" />
 
    <r:RibbonCommand x:Key="ApplicationMenuCommand"
        LargeImageSource="/MVVMRibbon;component/antoine64x64.jpg"
        SmallImageSource="/MVVMRibbon;component/antoine64x64.jpg" />
  </Window.Resources>
 
  <DockPanel LastChildFill="True">
    <r:Ribbon DockPanel.Dock="Top">
      <!--I hide the QuickAccessToolBar because I have no use of it-->
      <r:Ribbon.QuickAccessToolBar>
        <r:RibbonQuickAccessToolBar Visibility="Collapsed" />
      </r:Ribbon.QuickAccessToolBar>
 
      <!--Here is the ApplicationMenu : the bubble acting as a main menu in Office-->
      <r:Ribbon.ApplicationMenu>
        <r:RibbonApplicationMenu  Command="{StaticResource ApplicationMenuCommand}" />
      </r:Ribbon.ApplicationMenu>
 
      <!-- And finally the well-know "tabs"-->
      <r:RibbonTab Label="A first tab">
        <!--The controls are grouped in the tabs-->
        <r:RibbonGroup>
          <r:RibbonButton Command="{StaticResource MyFirstCommand}" />
        </r:RibbonGroup>
      </r:RibbonTab>
 
      <r:RibbonTab Label="A second tab"></r:RibbonTab>
    </r:Ribbon>
 
    <FlowDocumentReader />
  </DockPanel>
</Window>

Why using the RibbonCommand is broking the pattern

As you can see in the code above, when you declare the RibbonCommands in the XAML, you have to set a Execute and CanExecute event's handler. These handlers are set in the code behind and this is what breaks the pattern.

Sow why not only declare RibbonCommand inside the viewModels ? Because this will put presentation informations (those inside the RibbonCommand like images, description) inside the ViewModel which one must be decoupled from the way the data is presented.

Actually, only declaring RibbonCommands inside the ViewModel breaks the pattern because it exist a very strong link between the data and how it's presented in these objects.

An another thing is that you can't bind anything to the Ribbon commands because : A 'Binding' cannot be set on the 'XXX' property of type 'RibbonCommand'. A 'Binding' can only be set on a DependencyProperty of a DependencyObject.... Yes, a RibbonCommand is not a DependencyObject.

So I can't use the ribbon ?

Nooooo ! A solutions exists : first you can create some kind of proxies to the command which will make the commands available as a ressource in the views(CommandReference) through binding. Then the view will be responsible to create the RibbonCommands as they which from these commands in the ressources. To this purpose we'll have to extend the standard RibbonCommand to make them accepts a Command as a property.

Ok, ok, I heard your question : why not directy make the extended RibbonCommands acts as a proxy ? The answere is that RibbonCommand does not inherits from DependencyObject and so we can't bind anything on it ! (Which means, by the way, that we can't bind the commands of the viewModels directly to them).

I did not invent this technique, it's from :

• Integrating WPF Ribbon With Prism and MVVM (with VB.NET example)
• Codeplex forum

The proxy for the commands

As pointed out in this article I call them CommandReference.

We declare a DependencyProperty on which we will bind the command in the ViewModel. As you can see, this class is also a ICommand : all the calls will be translated to the binded command.

public class CommandReference : Freezable, ICommand
{
public static readonly DependencyProperty CommandProperty = 
  DependencyProperty.Register("Command", typeof(ICommand), typeof(CommandReference), 
     new PropertyMetadata(new PropertyChangedCallback(OnCommandChanged)));
public ICommand Command
{
  get { return (ICommand)GetValue(CommandProperty); }
  set { SetValue(CommandProperty, value); }
}
 
#region ICommand Members
public bool CanExecute(object parameter){ 
  return (Command != null) ?Command.CanExecute(parameter):false;
}
 
public void Execute(object parameter){ Command.Execute(parameter);}
 
public event EventHandler CanExecuteChanged;
private static void OnCommandChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
  CommandReference commandRef = d as CommandReference;
  if (commandReference != null)
  {
	ICommand lastCommand = e.OldValue as ICommand;
	if (oldCommand != null) lastCommand .CanExecuteChanged -= commandRef .CanExecuteChanged;
 
	ICommand nextCommand = e.NewValue as ICommand;
	if (newCommand != null) nextCommand .CanExecuteChanged += commandRef .CanExecuteChanged;
  }
}
#endregion
 
#region Freezable
protected override Freezable CreateInstanceCore()
{
  return new CommandReference();
}
#endregion

The extended RibbonCommands

We simply add a ICommand property to the RibbonCommand wich one we will be abble to fill in with a StaticRessource.

public class RibbonCommandExtended : RibbonCommand
{
  private ICommand _command;
  public ICommand Command
  {
    get { return _command; }
    set
    {
      _command = value;
      if (_command != null)
      {
        this.CanExecute += us_CanExecute;
        this.Executed += us_Executed;
      }
      else
      {
        this.CanExecute -= us_CanExecute;
        this.Executed -= us_Executed;
      }
    }
  }
 
  private void us_Executed(object sender, ExecutedRoutedEventArgs e)
  {
    Command.Execute(e.Parameter);
  }
 
  private void us_CanExecute(object sender, CanExecuteRoutedEventArgs e)
  {
    e.CanExecute = Command.CanExecute(e.Parameter);
  }
}

Then, what will my XAML looks like .

Here it is, especially for you, very simple :

<Window.Resources>
  <fwk:CommandReference x:Key="MyCommandReference"
      Command="{Binding MyViewModelCommand}" />
  <fwk:RibbonCommandExtended x:Key="cmd_MyCommand" LabelTitle="A labek"
      LabelDescription="A description"
      Command="{StaticResource MyCommandReference}"
      LargeImageSource="/MVVMRibbon;component/antoine64x64.jpg"
      SmallImageSource="/MVVMRibbon;component/antoine64x64.jpg" />
</Window.Resources>

Then you use the RibbonCommandExtended as you will have used the standard RibbonCommand.

Isn't it a little long to make something pretty simple ? The answer is definitively yes but the Microsoft seems to be working on new version of the ribbon which will respects the M-V-VM pattern...

Why not using our RamoraPattern ?

This is not possible because as I pointed out before, the RibbonCommands are not DependencyObject and so we can't attach properties to them !

Links

Here are some links you may find interesting on the same subjects :

• MapperCommandBinding - Mapping commands in WPF,
• A walktrough inside the ribbon functionnalities,
• A french article example of how to use the ribbon,
• Another WPF/C# ribbon

When you want to make an object binding-aware you have two choices : implement INotifyPropertyChanged or create DependencyProperties. Which one is the best ? Let's try to answer this question !

How to implement INotifyPropertyChanged

Declaring that your class is implementing INotifyPropertyChanged adds an PropertyChangedEventHandler that you raise for every changes of the properties. We also add a little tricky method checkIfPropertyNameExists(String propertyName) which checks by reflection when debugging if the property name really exists ! You usually ends up with code like this :

/// <summary>
/// Base class for all my viewModel.
/// </summary>
public class ViewModelBase : INotifyPropertyChanged
{
#region INotifyPropertyChanged Members
public event PropertyChangedEventHandler PropertyChanged;
public void FirePropertyChanged(String propertyName)
{
  checkIfPropertyNameExists(propertyName);
  PropertyChangedEventHandler handler = PropertyChanged;
  if (handler != null)
    handler.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
 
#endregion
 
[Conditional("DEBUG")]
private void checkIfPropertyNameExists(String propertyName)
{
  Type type = this.GetType();
  Debug.Assert(
    type.GetProperty(propertyName) != null,
    propertyName + "property does not exist on object of type : " + type.FullName);
}
}

As you can see, the code is quite easy to write and understand. You have to be very vigilant in checking the name of the property you gives as refactoring do not impacts Strings values but it stays quite simple.

DependencyProperties

MSDN definition of a DependencyProperty (link to) : a property that exists on a DependencyObject, is stored by the DependencyObject property store, and is identified by a DependencyProperty identifier on the owning DependencyObject.

Here is an example of how to create a DependencyProperty :

public class MyDependencyObject : System.Windows.DependencyObject
{
 public static readonly System.Windows.DependencyProperty MyDependencyPropertyProperty =
  System.Windows.DependencyProperty.Register("MyDependencyProperty", typeof(String), typeof(MyDependencyObject));
 
 public String MyDependencyProperty
 {
   get { return (String)GetValue(MyDependencyObject.MyDependencyPropertyProperty); }
   set { SetValue(MyDependencyObject.MyDependencyPropertyProperty, value); }
 }
}

Which one choose ?

Performances

All the tests are done under the .NET framework 4.0 with VisualStudio 2010 and .NET Memory Profiler 3.5.
The tests were already done on this page MVVM – Lambda vs INotifyPropertyChanged vs DependencyObject but I do not get the same results...

Execution times

To tests this I created a simple application and two textblocks binded to two String on my ViewModel. The tests were performed one by one and I took care to remove the inheritance of my ViewModel from DependencyObject when testing the INotifyPropertyChanged.

The code used to tests DependencyProperty is this one :

public static readonly DependencyProperty StringWithDependencyPropertyProperty =
DependencyProperty.Register("StringWithDependencyProperty", typeof(String), typeof(MainViewModel));
public String StringWithDependencyProperty
{
  get { return (String)GetValue(MainViewModel.StringWithDependencyPropertyProperty); }
  set { SetValue(MainViewModel.StringWithDependencyPropertyProperty, value); }
}
...
DateTime start = DateTime.Now;
for (int i = 0; i < 100000; i++)
  _mainViewModel.StringWithDependencyProperty = i.ToString();
DateTime end = DateTime.Now;
Console.WriteLine("Total time for DependencyProperty : " + (end - start).TotalMilliseconds +" ms.");

The code used to tests INotifyPropertyChangedis this one :

public String StringWithINotifyPropertyChanged
{
 get { return _stringWithINotifyPropertyChanged; }
 set
  {
    _stringWithINotifyPropertyChanged = value;
    firePropertyChanged("StringWithINotifyPropertyChanged");
  }
}
...
DateTime start = DateTime.Now;
for (int i = 0; i < 100000; i++)
  _mainViewModel.StringWithINotifyPropertyChanged = i.ToString();
DateTime end = DateTime.Now;
Console.WriteLine("Total time for INotifyPropertyChanged : " + (end - start).TotalMilliseconds+" ms.");

The results, for NO binding of the properties, were these :

Total time for DependencyProperty : 45 ms.
Total time for INotifyPropertyChanged : 171 ms.

The results, for one binding of the properties, were these :

Total time for DependencyProperty : 489 ms.
Total time for INotifyPropertyChanged : 1125 ms.

The results, for twelve binding of the properties, were these :

Total time for DependencyProperty : 3600ms.
Total time for INotifyPropertyChanged : 8375 ms.

==> DependencyProperty is 2,30 times faster than INotifyPropertyChanged for one binding and this number does not increase with the number of binded controls.!

Edit : as argued in the comments on codeProject and even if it is not the most common way to use INotifyPropertyChanged , I have made the tests with a static event args, and the results are :

Total time for no binding: 154ms
Total time for one binding: 770ms
Total time for twelve bindings: 5605ms

==> DependencyProperies are still better, even if it's less...

Memory usage

I executed the same code and profiled the memory usages :

DependencyProperty created 600 new instances and add 44,583 bytes INotifyPropertyChanged created 876 new instances and add 63,536 bytes

==> DependencyProperty seems (in my tests) to create less instance and to use less memory than the INotifyPropertyChanged system...

Inheritance issues

To create a DependencyProperty your objects needs to inherit from DependencyObject. This is not always possible and then using INotifyPropertyChanged is the only way to make it Bindable-aware.

Also, by being a DependencyObject, your object will carry with it all the dependency engine stuff and these limitations:

• only the thread that the DependencyObject was created on may access the DependencyObject directly.
• DependencyObject seals Equals and GetHashCode(),
• They are not marked as Serializable : (but you can use the XAMLWriter and XAMLReader to do so...

Inheritance from a base class you do not have a grip on ?=> No DependencyProperty !

Animations

Using DependencyProperty make the poperties animatable. If you want to animate a property, there is no simple work-around because, as the MSDN says : In order to be animated, the animation's target property must be a dependency property.

If you can't use DependencyProperty (when you do not create the objects for example), there is still work-arounds techniques.

Flexibility

Using INotifyPropertyChanged is sometimes more flexible than using DependencyProperty. Let me explain that. When you build a screen on which a lot of controls visibility dependsof some rules, you may declare a boolean which value is computed from other boolean.

For example, IsEditionPosible must be set to true only if IsAlreadyInEditionMode = false and if UserHasEditionRights = true. So when changing the value of IsAlreadyInEditionMode or UserHasEditionRights you must tells the binding engine that IsEditionPosible has been updated too. It's easier to do this with INotifyPropertyChanged than with the DependencyProperty with which you should have to create a method, which recalculate and reassign the new value to IsEditionPosible . Here you just have to use this little snippet :

public Boolean IsAlreadyInEditionMode 
{
 get { return _isAlreadyInEditionMode ; }
 set
  {
    _isAlreadyInEditionMode = value;
    firePropertyChanged("IsAlreadyInEditionMode ");
    firePropertyChanged("IsEditionPosible");
  }
}
 
public Boolean UserHasEditionRights 
{
 get { return _userHasEditionRights ; }
 set
  {
    _userHasEditionRights = value;
    firePropertyChanged("UserHasEditionRights");
    firePropertyChanged("IsEditionPosible");
  }
}
 
public Boolean IsEditionPosible
{
 get { return UserHasEditionRights && !IsAlreadyInEditionMode  ; }
}

Note that this is the way that I create computed value for easier binding in my viewModel but this is a subject where improvments may be done...

Flexibility (easier code writing) needed ?=> Choose INotifyPropertyChanged !

Testing

When you performs testing on your object, you will be in trouble if you use DependencyObject : the test are not done on the same thread that created the object and then throws you a "System.InvalidOperationException: The calling thread cannot access this object because a different thread owns it".

Testing => No DependencyProperty !

Code Readability/writing

Some people argues that the use of DependencyProperties the code extremely ugly. I myself think that this is exaclty the same. To make easier the creation of dependencyProperty you can use this snippet : link to the snippet

Links of articles on the same subject :

• MVVM – Lambda vs INotifyPropertyChanged vs DependencyObject ( I have not the same results !)
• View Models: POCOs versus DependencyObjects

The problem

In WPF you expect your components/controls to behave exactly as you want to.... but this not always the case.
For example : why does this combobox not execute a command when I change the selection or more often why this textbox does not execute a command when I press the Enter (return) key ?

This problem often occurs when you use the - well know - pattern M-V-VM and it's sometimes hard to find a workaround. Today I will explain you a design pattern, know as the Ramora pattern which I find very useful.
By the way, you can also use it to create a library of behaviors for all your projects...

Wanted application

One solution (or the ramora pattern explained)

The idea

The solution is based on the attached properties (MSDN page here) of the WPF binding engine. With this mechanism you can attach any property to any object you want and it's massively used in layout controls (DockPanel.Dock for example)..

By attaching and detaching properties we will attach some handlers on the events of our choice to add behaviors to the controls. The value passed by the property will also be useful as a data storage....

The steps are :

1. Create a class of your choice, no inheritance needed,
2. Declare an attachedProperty by registering it and adding the corresponding GetXXX and SetXXX,
3. Add an event handler to the change of this property : inside it, add an event handler to the event you want to catch (for example MouseEnter),
4. Add the behavior logic inside this last event handler
5. Attach this behaviors to the aimed control inside your XAML (after you'd declared the XMLNS)

An example

In this example we'll try to add a nice beahavior to any IInputElement : anytime the user presses the 'Enter' key, it will execute a Command.

We'll then declare a Command attached property of type 'ICommand' which will be the command to execute on a given event (very original isnt it ?).

#region Command Property
/// <summary>
/// Enables Command functionality
/// </summary>
public static ICommand GetCommand(DependencyObject obj)
{
	return (ICommand)obj.GetValue(CommandProperty);
}
 
/// <summary>
/// Enables Command functionality
/// </summary>
public static void SetCommand(DependencyObject obj, ICommand value)
{
	obj.SetValue(CommandProperty, value);
}
 
/// <summary>
/// Enables Command functionality
/// </summary>
public static readonly DependencyProperty CommandProperty =
	DependencyProperty.RegisterAttached("Command",
 typeof(ICommand),
 typeof(CommandOnEnter), 
new UIPropertyMetadata(null, new PropertyChangedCallback(CommandPropertyChanged)));

Then everytimes the property is assigned we will attach or detach our event handlers on the DependencyObject which uses it. In our case this is an IInputElement.

/// <summary>
/// Command property changed callback
/// </summary>        
static void CommandPropertyChanged(DependencyObject sender, DependencyPropertyChangedEventArgs e)
{
	//Test in debug mode if it's binded to the correct type of element...
	Debug.Assert(sender is IInputElement, "Attached property only for a IInputElement");
	if (sender is IInputElement)
	{
		IInputElement inputElement = sender as IInputElement;
 
		// Clean when Command is released
		if (e.OldValue != null)
		{
			Detach(inputElement);
		}
 
		//Attach the behavior
		if (e.NewValue != null)
		{
			Attach(inputElement);
		}
 
	}
}
 
/// <summary>
/// Clean event handlers
/// </summary>
/// <param name="inputElement">The aimed IInputElement</param>
private static void Detach(IInputElement inputElement)
{
	inputElement.PreviewKeyDown -= CommandOnEnter_PreviewKeyDown;
	if (inputElement is FrameworkElement)
		(inputElement as FrameworkElement).Unloaded -= CommandOnEnter_Unloaded;
}
 
 
private static void Attach(IInputElement inputElement)
{
	inputElement.PreviewKeyDown += new KeyEventHandler(CommandOnEnter_PreviewKeyDown);
	if (inputElement is FrameworkElement)
		(inputElement as FrameworkElement).Unloaded += new RoutedEventHandler(CommandOnEnter_Unloaded);
 
}

The keyPressed event handler checks if the enter key is pressed and execute the command if yes. The command to execute is retrieved via the attachedProperties system of WPF (GetValue method) :

static void CommandOnEnter_PreviewKeyDown(object sender, System.Windows.Input.KeyEventArgs e)
{
	if (sender is IInputElement)
	{
		var textBox = sender as IInputElement;
		if (e.Key == Key.Enter && e.KeyboardDevice.Modifiers == ModifierKeys.None)
		{
			ICommand cmd = GetCommand(sender as DependencyObject) as ICommand;
			cmd.Execute(null);
		}
 
	}
}

That's all !

Adding a parameter ?

What if you want to pass a parameter to the executed Command ? You will simply have to add another Attached property and get it's value in the keyPressed event handler.

/// <summary>
/// Enables CommandParameter functionality
/// </summary>
public static object GetCommandParameter(DependencyObject obj)
{
	return (object)obj.GetValue(CommandParameterProperty);
}
 
/// <summary>
/// Enables CommandParameter functionality
/// </summary>
public static void SetCommandParameter(DependencyObject obj, object value)
{
	obj.SetValue(CommandParameterProperty, value);
}
 
/// <summary>
/// Enables CommandParameterProperty functionality
/// </summary>
public static readonly DependencyProperty CommandParameterProperty =
	DependencyProperty.RegisterAttached("CommandParameterProperty", typeof(object), typeof(CommandOnEnter));

Funny things to do

The ramora pattern can be used to do a lot of things, here is a list of some I'am thinking :

• Execute a command on a textbox when pressing enter,
• Select all the text when a textbox gets the focus,
• Etc...

Here are some links you may find useful :

1. Thinking in WPF: attached properties
2. More advanced attached property use: the Ramora pattern
3. Behaviors in Silverlight 4.0