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

2011

2010

2009

2008

Tag - DependencyObject

Entries feed - Comments feed

 

Execute a command on a specified control when clicking on a button

16 June 2010

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



Shout it kick it on DotNetKicks.com Awaaz Up


 

Binding to the selected items of a ListBox (or an another items controls)

13 June 2010

A problem you often meet when using MVVM is to get the selected items of an items control, especially Listbox.

You can easily bind the selected item or the current items but when multi selection comes in the way, it becomes harder because the SelectedItems (with an 's' property is not available to binding).

In this article we will discover an easy way to bind yourself with an attached property to the SelectedItems property of the ListBox control.



We will use the Ramora pattern discussed before to bind ourself to the ListBox's selectionChanged events and then update the target list when the selection change.

If the target list implements INotifyCollectionChanged we will update the listbox selection when this event is raised.

Here is the resulting code :

public class ListBoxSelectedItemsSyncher : DependencyObject
{
  private static List<Syncher> _synchers = new List<Syncher>();
 
  #region ListToSync
 
  /// <summary>
  /// ListToSync Attached Dependency Property
  /// </summary>
  public static readonly DependencyProperty ListToSyncProperty =
    DependencyProperty.RegisterAttached("ListToSync", 
	             typeof(IList), typeof(ListBoxSelectedItemsSyncher),
      new FrameworkPropertyMetadata((IList)new List<Object>(),
        FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, 
		       new PropertyChangedCallback(OnListToSyncChanged)));
 
 
  private static void OnListToSyncChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
  {
    ListBox listBox = d as ListBox;
 
    if(!(d is ListBox)
     throw new ArgumentException("ListBoxSelectedItemsSyncher is only applyable to Listbox");
 
    Syncher synch = (from Syncher syncher 
	              in _synchers where syncher.ListBox == listBox select syncher)
                             .FirstOrDefault();
    if (synch != null)
    {
      synch.ListToSync = e.NewValue as IList;
    } else
    {
      synch = new Syncher(listBox, e.NewValue as IList);
      _synchers.Add(synch);
      listBox.Unloaded += new RoutedEventHandler(listBox_Unloaded);
    }
  }
 
  static void listBox_Unloaded(object sender, RoutedEventArgs e)
  {
    ListBox listBox = sender as ListBox;
    Syncher synch = (from Syncher syncher 
	              in _synchers where syncher.ListBox == listBox select syncher)
                      .FirstOrDefault();
    if (synch != null)
    {
      _synchers.Remove(synch);
      synch.Dispose();
      synch = null;
    }
  }
 
  /// <summary>
  /// Gets the ListToSync property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static IList GetListToSync(DependencyObject d)
  {
    return (IList)d.GetValue(ListToSyncProperty);
  }
 
  /// <summary>
  /// Sets the ListToSync property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static void SetListToSync(DependencyObject d, IList value)
  {
    d.SetValue(ListToSyncProperty, value);
  }
 
  #endregion
 
 
  internal class Syncher : IDisposable
  {
 
    private ListBox _listbox;
    public ListBox ListBox { get { return _listbox; } }
 
    private IList _listToSync;
    public IList ListToSync
    {
      get { return _listToSync; }
 
      set
      {
        detachTheListToSynch();
        _listToSync = value;
        attachTheListToSynch();
      }
    }
 
    public Syncher(ListBox listbox, IList listToSync)
    {
      _listbox = listbox;
      _listToSync = listToSync;
      attachTheListToSynch();
    }
 
    void collectionChangedList_CollectionChanged(object sender,
                        	NotifyCollectionChangedEventArgs e)
    {
      //Add new items   
      if (e.NewItems != null)
      {
        foreach (Object item in e.NewItems)
        {
          _listbox.SelectedItems.Add(item);
        }
      }
      if (e.OldItems != null)
      {
        foreach (Object item in e.OldItems)
        {
          _listbox.SelectedItems.Remove(item);
        }
      }
 
      if (e.Action == NotifyCollectionChangedAction.Reset)
        _listbox.SelectedItems.Clear();
 
      CommandManager.InvalidateRequerySuggested();
    }
 
    void _list_SelectionChanged(object sender, SelectionChangedEventArgs e)
    {
      if (_listToSync != null)
      {
        //Add new items                   
        foreach (Object item in e.AddedItems)
        {
          _listToSync.Add(item);
        }
        foreach (Object item in e.RemovedItems)
        {
          _listToSync.Remove(item);
        }
        CommandManager.InvalidateRequerySuggested();
      }
    }
 
    #region IDisposable Members
    public void Dispose()
    {
      if (_listbox == null) return;
      _listbox.SelectionChanged -= _list_SelectionChanged;
      detachTheListToSynch();
      _listbox = null;
    }
    #endregion
 
    #region private methods
    private void attachTheListToSynch()
    {
      _listbox.SelectionChanged -= _list_SelectionChanged;
      if (_listToSync == null) return;
 
      INotifyCollectionChanged collectionChangedList = null;
      if ((collectionChangedList = _listToSync as INotifyCollectionChanged) != null)
        collectionChangedList.CollectionChanged 
	  += new NotifyCollectionChangedEventHandler(collectionChangedList_CollectionChanged);
 
      //Update the selection with the new list
      _listbox.SelectedItems.Clear();
 
      foreach (var item in _listToSync)
        _listbox.SelectedItems.Add(item);
 
      _listbox.SelectionChanged 
	       += new SelectionChangedEventHandler(_list_SelectionChanged);
    }
 
    private void detachTheListToSynch()
    {
      INotifyCollectionChanged collectionChangedList = null;
      if ((collectionChangedList = _listToSync as INotifyCollectionChanged) != null)
        collectionChangedList.CollectionChanged -= collectionChangedList_CollectionChanged;
    }
    #endregion
 
  }
 }


Here we are.

Edit : I found out later an another version of the same feature made by Samuel Jack on his blog : http://blog.functionalfun.net/2009/02/how-to-databind-to-selecteditems.html !



Shout it kick it on DotNetKicks.com


 

MVVM - How to integrate the Office Ribbon respecting the pattern (especially the commands)

4 March 2010

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 : MVVMRibbonExample

<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 :



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 :


Shout it kick it on DotNetKicks.com



 

DependencyProperties or INotifyPropertyChanged ?

1 March 2010

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.

DPvsInotifyPropertyChangedExecTimeChart
==> 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

DPvsInotifyPropertyChangedMemoryUsageChart
==> 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:


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 :



Shout it kick it on DotNetKicks.com


 

CREATE, LAUNCH and CONTROL a WPF animation FROM CODE

7 July 2009

The problem

Sometimes you need to animate your specific object and for this purpose there is the WPF animation.

Here are the prerequireds :

  • The property you want to animate must be a DependencyProperty,
  • The property must so be a part of a DependencyObject,
  • Your object must implement IAnimatable to be able to launch the animation.


The difficulty resides in being able to create an animation, create a storyboard and set the corrects values for the attached properties - TargetName and TargetProperty - on the animation. All of this directly in the code.

You can then control the animation, the usual way than in XAML.

My solution/checklist

Here is how I did it, step by step.

First I make my business object derives from FrameWorkElement. Why ?
Because, this make my object a dependency object. Also, my object will implements IAnimatable ( FrameWorkElement heritate from UIElement which implements IAnimatable). And finally, it gets a NameScope which will be used later.
So here is my object:

public class Puppet: FrameworkElement {    }



Next I will had a DependencyProperty to be animated. Here I animate a value of type Point. I create all the usual things for the dependencyProperty and also add a storyboard (I will always use the same):

public class Puppet: FrameworkElement
{
   public static DependencyProperty ContactMovementProperty =
   DependencyProperty.Register("ContactMovement", typeof(Point), typeof(Puppet));
 
   public Point ContactMovement
   {
       get { return (Point)GetValue(SatelliteNavigator.ContactMovementProperty); }
       set { SetValue(SatelliteNavigator.ContactMovementProperty, value); }
    }
 
    private Storyboard stboard = new Storyboard();
}



Then, let's say I will create and launch the animation directly in the constructor. Here is the code added :

public class()
{
   //Maybe it was running before (if not set in the constructor)
   //stboard.Stop();
 
    double xFinal = 36;
    double yFinal = 36;
    PointAnimation animation = new PointAnimation();
 
    animation.From = ContactMovement;
    animation.To = new Point(xFinal , yFinal );
    animation.Duration = TimeSpan.FromMilliseconds(e.Velocity.Length*7 / deceleration);
    animation.AccelerationRatio = 0f;
    animation.DecelerationRatio = 0.4f;
    String puppetName= "puppet";
 
    NameScope nams = new NameScope();
    NameScope.SetNameScope(this, nams);
    this.RegisterName(puppetName, this);
 
    Storyboard.SetTargetName(animation, puppetName);
    Storyboard.SetTargetProperty(animation, new PropertyPath(Puppet.ContactMovementProperty));
 
    stboard.Children.Add(animation);
    stboard.Begin(this);
 
}


What is done ? First I create the animation with random values for our example.
Then I create a NameScope and set it to our object. Why ? Because it's not created by the runtime for our object and we need one. It will be used by the animation to retrieve the object to animate.

This is done by registering the Puppet object in the namescope and giving the same TargetName of the attachedProperty of the animation(Storyboard.SetTargetName).

Then we clear the children animation of the storyboard (maybe it was not empty) and launch the storyboard by giving it the Puppet (object in which the animated object is).



We can then use the usual methods on storyboard to control the play of the media. For example :

stboard.Stop();


Conclusion

As you can see this is not as easy as writing some XAML lines but it's not impossible !

Any questions ?

kick it on DotNetKicks.com


Shout it


 

Use dataBinding and DependencyProperty with a non-WPF or extern object

10 April 2009

Today we are going to learn how we can uses the powerful data binding of WPF even on non-WPF objects.

The problem: when to use this solution ?

Sometimes you need to use the databinding with an object that you have not created and you can't use inheritance.

For example I wanted to use a Mogre Camera and build some WPF animation with it and I couldn't because :

  • WPF animation needed a DependencyProperty to manipulate,
  • I couldn't derive the Mogre.Camera class and add it the correct things because I got the camera from a factory object (the sceneManager).



Then I couldn't use the WPF animation to move my camera... next is how I solve it.

A solution: mine and surely not the best ;-)

Here is the solution i use:

  1. Create a proxy DependencyProperty inside a DependencyObject, for example your main windows.
  2. Override the OnPropertyChanged handler.
  3. Update the aimed attribute inside the handler.


To control my camera, I created this DependencyProperty inside my windows:

public static readonly DependencyProperty CameraPositionProperty = DependencyProperty.Register("CameraPosition", typeof(Point3D), typeof(SurfaceWindow1), new PropertyMetadata(new Point3D(0, 0, 0)));
 
      public Point3D CameraPosition
      {
         get
         {
            return (Point3D)GetValue(CameraPositionProperty);
         }
         set
         {
            SetValue(CameraPositionProperty, value);
         }
      }


Then I added this override :

protected override void OnPropertyChanged(DependencyPropertyChangedEventArgs e)
      {
         base.OnPropertyChanged(e);
         if (e.Property.Name.Equals("CameraPosition"))
         {
            _ogre.Camera.SetPosition((float)((Point3D)e.NewValue).X, (float)((Point3D)e.NewValue).Y, (float)((Point3D)e.NewValue).Z);
            _ogre.Camera.LookAt(Vector3.ZERO);
         }
      }



And my usual question :

Does someone have a better idea to perform the same ?