On developing Pochet.NET

Memory Leak in PanelDragDropTarget

Emiel — Sat, 16 Oct 2010 14:10:07 +0000

While implementing drag-and-drop grouping for the Silverlight DataGrid I noticed that the PanelDragDropTarget contains a memory leak:

Whenever you add a user control containing a PanelDragDropTarget to a page and then remove the user control from this page, the user control is not properly released.

When you replace the PanelDragDropTarget with another control, e.g. a ListBox, the user control is released.

The root cause of this problem is probably the fact that the base class DropDragTarget attaches some events to the Canvas of the Application.Current which are not removed.

I have created a sample project that demonstrates the problem using the MemoryLeakDetector which can be downloaded here.

This issue has been reported to the Silverlight Toolkit team here where you can vote for this issue to be solved.

Datagrid: support for grouping on columns use IValueConverters to display their value and conditonal rowstyling

Emiel — Mon, 06 Sep 2010 13:55:35 +0000

Introduction

Some further enhancements have been made to the DataGrid wrapper that has been the subject of this previous post:

Support for grouping on columns that use IValueConverter to display their value
Conditional row styling

This post is a code drop for these enhancements.

Conditional row styling

The following code gives a sample on how to use conditional row styling:

public MainPage()
{
    InitializeComponent();
 
    theDataGrid.ItemsSource = PersonFactory.GetAllPersons();
 
    theDataGrid.RowStyles.Add(new MyDataGridRowConditionalStyle(
        (o) => { return ((Person)o).Name.Contains("A"); },
        new MyDataGridRowStyle()
        {
            Background = new SolidColorBrush(Colors.Yellow),
            ToolTip = "Name contains an 'A'"
        }
        ));
    theDataGrid.RowStyles.Add(new MyDataGridRowConditionalStyle(
        (o) => { return ((Person)o).Name.Contains("C"); },
        new MyDataGridRowStyle()
        {
            Foreground = new SolidColorBrush(Colors.Red),
            ToolTip = "Name contains a 'C'"
        }
        ));
    theDataGrid.RowStyles.Add(new MyDataGridRowConditionalStyle(
        (o) => { return ((Person)o).Name.Contains("N"); },
        new MyDataGridRowStyle()
        {
            FontSize = 14,
            FontWeight = FontWeights.ExtraBold,
            ToolTip = "Name contains an 'N'"
        }
        ));
}

The result can be seen in the picture above

Download

The sources can be downloaded here.

Additional remarks

A solution for conditional cell styling can be found here

Update postings on Datagrid

Emiel — Sun, 29 Aug 2010 20:51:06 +0000

Recently I wrote two posts on the Silverlight Datagrid:

Andy noticed that in a comment that the synchronizing of the group row headers with the column headers did not work correctly when the group headers were scrolled out of view and then back into view again.

After investigating the reason of this behavior I have decided to take another approach and to re-implement this functionality. Some additional testing of this new implementation reveals that the issue reported by Andy has been solved. The only quirk now is that whenever the short description of the Display attribute is set on a property of the data and the Header of the column is explicitly set, the column will show the header and the group row the short descriptions.

This new approach to synchronizing the group headers with the column headers is now also used in the implementation of the Drag and Drop grouping. As it turned out, this synchronizing approach simplified the implementation of Drag and drop grouping, because the cloning of the CollectionView was not needed anymore. Also after applying the grouping the selected elements would still be selected.

Finally some additional changes have been made:

A dialog for selecting columns has been added
Reordering of the groups is supported
The column by which is grouped is automatically hidden
The components are wrapped in a reusable DLL

The modified code can be downloaded here.

Update

The code from this post has been updated. A newer version can be downloaded from here

Drag and Drop grouping in Datagrid

Emiel — Wed, 25 Aug 2010 14:08:31 +0000

Update

The code for the functionality in this post has been updated in Update postings on Datagrid

Introduction

The DataGrid of the Silverlight Toolkit supports grouping but does not have the ability to drag column headers to the area above the grid to group the data, unlike some other 3^rd party datagrids.

This blog presents a solution to implement this functionality. The solution is based upon the solution which can be found on the blog Lee’s corner.

Introduction
Shortcomings of Lee’s solution
Make reusable
Alternative for replacing the template
Preventing column order changes when grouping
Match column headers with group headers
- Match with group rows within the MyDataGrid
- Match with MyDataGridGroupHeaderPanel
Download

Shortcomings of Lee’s solution

The solution presented on Lee’s corner has the following shortcomings:

The solution is not a reusable component
The solution is not themable because the Template is replaced
When grouping on column, the order of the columns is also changed as noticed by Robbie Symborski
Headers on columns do not match group headers

The following paragraphs outline the approaches taken to resolve these shortcomings.

Make reusable

Because integrating the group header panel within the datagrid without changing the template seemed quite complex, the solution consists of the following two components:

MyDataGrid: inherited from DataGrid
MyDataGridGroupHeaderPanel: group panel that can be linked to the MyDataGrid by using the attribute DataGrid

Using these components a groupable grid can be made as follows:

>
    >
         Height="40"/>
         Height="*"/>
    >
 
     DataGrid="{Binding ElementName=datagrid1}" Grid.Row="0"/>
 
     x:Name="datagrid1" Grid.Row="1" ...>
        ...
    >
>

The underlying DataGrid relies on a ICollectionView to perform the grouping and sorting. Unfortunately, there is no way to get hold of this data from within the DataGrid itself. The solution is to use an ICollectionView for the ItemsSource and keep a reference to this ICollectionView. In order to be able to still support ordinary IEnumerable item sources the ItemsSource property of the underlying DataGrid is hidden by a new definition as follows:

public ICollectionView CollectionView { get; private set; }
 
public new IEnumerable ItemsSource
{
    get { return GetValue(ItemsSourceProperty) as IEnumerable; }
    set { SetValue(ItemsSourceProperty, value); }
}
 
public static new readonly DependencyProperty ItemsSourceProperty =
    DependencyProperty.Register(
    "ItemsSource",
    typeof(IEnumerable),
    typeof(MyDataGrid),
    new PropertyMetadata(OnItemsSourcePropertyChanged));
 
private static void OnItemsSourcePropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    MyDataGrid grid = d as MyDataGrid;
    if (grid == null)
    {
        return;
    }
 
    grid.SetItemsSource((IEnumerable)e.NewValue);
}
 
private void SetItemsSource(IEnumerable itemsSource)
{
    ICollectionView newValue = CreateCollectionView(itemsSource);
 
    CollectionView = newValue;
    base.ItemsSource = newValue;
}
 
private static ICollectionView CreateCollectionView(IEnumerable newItemsSource)
{
    if (newItemsSource == null)
    {
        return null;
    }
 
    ICollectionViewFactory collectionViewFactory = newItemsSource as ICollectionViewFactory;
    if (collectionViewFactory != null)
    {
        return collectionViewFactory.CreateView();
    }
 
    ICollectionView collectionView = newItemsSource as ICollectionView;
    if (collectionView != null)
    {
        return collectionView;
    }
 
    return new PagedCollectionView(newItemsSource);
}

Alternative for replacing the template

As stated in here the only reason to replace the Template is to wrap the DataGridColumnHeadersPresenter in a PanelDragDropTarget to allow the DataGridColumnHeaders to be draggable. This can also be done by overriding the OnApplyTemplate() of MyDataGrid like this:

PanelDragDropTarget _dropTarget;
 
public override void OnApplyTemplate()
{
    base.OnApplyTemplate();
 
    DataGridColumnHeadersPresenter columnHeadersPresenter = this.GetTemplateChild("ColumnHeadersPresenter") as DataGridColumnHeadersPresenter;
    if (columnHeadersPresenter == null)
    {
        return;
    }
 
    Grid columnHeadersPresenterParent = columnHeadersPresenter.Parent as Grid;
    if (columnHeadersPresenterParent == null)
    {
        return;
    }
 
    int indexOfPresenter = columnHeadersPresenterParent.Children.IndexOf(columnHeadersPresenterParent);
    if (indexOfPresenter == -1)
    {
        indexOfPresenter = 1;
    }
 
    _dropTarget = new PanelDragDropTarget() 
    { 
        HorizontalContentAlignment = HorizontalAlignment.Stretch, 
        VerticalContentAlignment = VerticalAlignment.Stretch, 
        AllowedSourceEffects = DragDropEffects.Copy 
    };
    _dropTarget.SetValue(Grid.ColumnProperty, 1);
 
    columnHeadersPresenterParent.Children.Remove(columnHeadersPresenter);
 
    columnHeadersPresenter.ClearValue(Grid.ColumnProperty);
    columnHeadersPresenter.ClearValue(Grid.RowProperty);
 
    _dropTarget.Content = columnHeadersPresenter;
    columnHeadersPresenterParent.Children.Insert(indexOfPresenter, _dropTarget);
}

Preventing column order changes when grouping

The problem in preventing column order changes when regrouping is how to determine when a column header movement is a column order change or a group change. The approach taken in this solution is a pragmatic one: when the control key is pressed during the mousedown on a column header the user is starting a group operation, otherwise the user is starting a column reorder operation. This can be achieved by addint the folowing to code to MyDataGrid:

protected virtual bool AllowGrouping
{
    get
    {
        return (Keyboard.Modifiers & ModifierKeys.Control) != ModifierKeys.None;
    }
}
 
protected override void OnMouseLeftButtonDown(MouseButtonEventArgs e)
{
    CanUserReorderColumns = !AllowGrouping;
 
    base.OnMouseLeftButtonDown(e);
}

and to add the following line to the OnApplyTemplate() override:

_dropTarget.ItemDragStarting += (s, e) => { e.Cancel = !AllowGrouping; if (e.Cancel) { e.Handled = true; } };

Match column headers with group headers

The column headers must match with both:

the group headers on the group rows within the MyDataGrid
the group buttons on MyDataGridGroupHeaderPanel

These are separate problems which will be dealt with in the following paragraphs.

Match with group rows within the `MyDataGrid`

Following this article the matching with group rows within the MyDataGrid can be achieved by adding the following code to MyDataGrid:

protected override void OnLoadingRowGroup(DataGridRowGroupHeaderEventArgs e)
{
    base.OnLoadingRowGroup(e);
 
    string fieldName = e.RowGroupHeader.PropertyName;
 
    e.RowGroupHeader.PropertyName = GetColumnCaptionFromBindingPath(fieldName) ?? fieldName;
}
 
public string GetColumnCaptionFromBindingPath(string bindingPath)
{
    foreach (DataGridBoundColumn column in this.Columns)
    {
        if (column == null)
        {
            continue;
        }
        Binding binding = column.Binding;
        if (binding == null)
        {
            continue;
        }
        if (binding.Path.Path == bindingPath)
        {
            return Convert.ToString(column.Header);
        }
    }
 
    return null;
}

Unfortunately, this only seems to work on initial binding. Whenever an ICollectionView is bound to a DataGrid and the sorting or grouping is changed, either by changing the SortDescriptions, changing the GroupDescriptions or by changing the sort order by clicking on the column headers, the column name is used in stead of the header name. This is probably a bug within the DataGrid component. A work around this problem is to clone the ICollectionView and assign this clone to the ItemsSource of the DataGrid by replacing the definition of SetItemsSource by this

private void SetItemsSource(IEnumerable itemsSource)
{
    ICollectionView oldValue = CollectionView;
    if (oldValue != null)
    {
        (oldValue.SortDescriptions as INotifyCollectionChanged).CollectionChanged -= OnChangeRebindCollection;
        oldValue.GroupDescriptions.CollectionChanged -= OnChangeRebindCollection;
    }
 
    ICollectionView newValue = CreateCollectionView(itemsSource);
    if (newValue != null)
    {
       (newValue.SortDescriptions as INotifyCollectionChanged).CollectionChanged += OnChangeRebindCollection;
        newValue.GroupDescriptions.CollectionChanged += OnChangeRebindCollection;
    }
 
    CollectionView = newValue;
    base.ItemsSource = newValue;
}

and to add the following functions:

private void OnChangeRebindCollection(object sender, NotifyCollectionChangedEventArgs e)
{
    Rebind();
}
 
public void Rebind()
{
    ItemsSource = CollectionView.Clone();
}

Unfortunately reassigning the ItemsSource or the base.ItemsSource does not work. Because the class PagedCollectionView that is used for implementing the CollectionView does not implement a Clone method, the following extension method is created:

public static ICollectionView Clone(this ICollectionView source)
{
    if (source == null)
    {
        return null;
    }
 
    PagedCollectionView result = new PagedCollectionView(source.SourceCollection);
 
    if (source.Culture != null)
    {
        result.Culture = source.Culture;
    }
 
    if (source.Filter != null)
    {
        result.Filter = source.Filter;
    }
 
    foreach (SortDescription sortDescription in source.SortDescriptions)
    {
        result.SortDescriptions.Add(sortDescription);
    }
 
    foreach (GroupDescription groupDescription in source.GroupDescriptions)
    {
        result.GroupDescriptions.Add(groupDescription);
    }
 
    IPagedCollectionView pagedCollectionView = source as IPagedCollectionView;
    if (pagedCollectionView != null)
    {
        result.PageSize = pagedCollectionView.PageSize;
    }
 
    return result;
}

Unfortunately, for some reason or another, the addition of

    result.MoveCurrentTo(source.CurrentItem);

leads to the following exception:

Cannot change or check the contents or current position of the PagedCollectionView while Refresh is being deferred.

This is probably a bug in the implementation of PagedCollectionView: probably the raising of the event INotifyCollectionChanged.CollectionChanged is made before all IDisposable‘s returned from the internal calls to DeferRefresh have been disposed. As a consequence of this, it is not possible to keep the selected item selected after regrouping or sorting.

Finally: in order to enable prevention of multiple rebindings of the ItemsSource, the method Rebind() described in this article is refactored as follows:

public void Rebind()
{
    PostponableRebind.Execute();
}
 
private PostponableAction _postponableRebind;
private PostponableAction PostponableRebind
{
    get
    {
        if (_postponableRebind == null)
        {
            _postponableRebind = new PostponableAction(RebindImplementation);
        }
        return _postponableRebind;
    }
}
 
public IDisposable PostponeRebind
{
    get
    {
        return PostponableRebind.PostponeAction;
    }
}
 
private void RebindImplementation()
{
    ItemsSource = CollectionView.Clone();
}

Match with `MyDataGridGroupHeaderPanel`

In order to support column headers that differ from the column binding names in the MyDataGridGroupHeaderPanel, instances of the inner class GroupDefinition are used as items of the ListBox in stead of the actual headers. This inner class is defined as follows:

private class GroupDefinition
{
    public GroupDefinition(string field, string caption)
    {
        if (String.IsNullOrEmpty(field))
        {
            throw new ArgumentNullException("field");
        }
 
        Field = field;
        Caption = caption ?? field;
    }
 
    public string Field { get; internal set; }
    public string Caption { get; internal set; }
 
    public override string ToString()
    {
        return Caption;
    }
}

The Drag event handler that adds an item to the ListBox becomes:

protected void DragDropTarget_Drop(object sender, Microsoft.Windows.DragEventArgs e)
{
    if (DataGrid == null)
    {
        return;
    }
 
    object data = e.Data.GetData(e.Data.GetFormats()[0]);
    if (data == null)
    {
        return;
    }
 
    DataGridColumnHeader dgch = ((data as ItemDragEventArgs).Data as SelectionCollection)[0].Item as DataGridColumnHeader;
    if (dgch == null)
    {
        return;
    }
 
    string caption = Convert.ToString(dgch.Content);
    string fieldName = DataGrid.GetBindingPathFromColumnCaption(caption);
 
    using (OnHeaderItemsChanged.PostponeAction)
    {
        foreach (GroupDefinition item in listGroups.Items)
        {
            if (item.Field == fieldName)
            {
                listGroups.Items.Remove(item);
                break;
            }
        }
        listGroups.Items.Add(new GroupDefinition(fieldName, caption));
    }
}

Note that extra logic has been added to prevent a single column to be added twice. Unfortunately it is not possible to get the column definition from the DataGridColumnHeader, so the binding name has to be retrieved using the function DataGrid.GetBindingPathFromColumnCaption which is defined in MyDataGrid as

public string GetBindingPathFromColumnCaption(string columnCaption)
{
    DataGridBoundColumn column = Columns.FirstOrDefault((c) => Convert.ToString(c.Header) == columnCaption) as DataGridBoundColumn;
    if (column == null)
    {
        return null;
    }
    Binding binding = column.Binding;
    if (binding == null || binding.Path == null)
    {
        return null;
    }
 
    return binding.Path.Path;
}

The actual synchronization of the GroupDescriptions is moved to the CollectionChanged event handler of the ListBox which is defined as follows:

(listGroups.Items as INotifyCollectionChanged).CollectionChanged += (s, e) => { OnHeaderItemsChanged.Execute(); };

with the following supporting definitions:

private PostponableAction _onHeaderItemsChanged;
private PostponableAction OnHeaderItemsChanged
{
    get
    {
        if (_onHeaderItemsChanged == null)
        {
            _onHeaderItemsChanged = new PostponableAction(OnHeaderItemsChangedImplementation);
        }
        return _onHeaderItemsChanged;
    }
}
 
private void OnHeaderItemsChangedImplementation()
{
    if (DataGrid == null)
    {
        return;
    }
 
    ICollectionView view = DataGrid.CollectionView;
    if (view == null)
    {
        return;
    }
 
    ObservableCollection<GroupDescription> groupDescriptions = view.GroupDescriptions;
    if (groupDescriptions == null)
    {
        return;
    }
 
    using (DataGrid.PostponeRebind)
    {
        groupDescriptions.Clear();
        if (listGroups.Items != null)
        {
            foreach (GroupDefinition groupDefinition in listGroups.Items)
            {
                groupDescriptions.Add(new PropertyGroupDescription { PropertyName = groupDefinition.Field });
            }
        }
    }
}

The ListBox is initially filled by

private void FillGroupHeaderPanelFromGroupDescriptions()
{
    using (OnHeaderItemsChanged.PostponeAction)
    {
        listGroups.Items.Clear();
 
        if (DataGrid == null)
        {
            return;
        }
 
        ICollectionView collection = DataGrid.CollectionView;
        if (collection == null)
        {
            return;
        }
 
        foreach (PropertyGroupDescription groupDescription in collection.GroupDescriptions)
        {
            listGroups.Items.Add(new GroupDefinition(groupDescription.PropertyName, DataGrid.GetColumnCaptionFromBindingPath(groupDescription.PropertyName)));
        }
    }
}

Download

The source accompanying this blog can be downloaded here.

Postponing actions

Emiel — Wed, 25 Aug 2010 08:10:27 +0000

Introduction

Often modifications to an object (setting properties or calling methods etc.) cause synchronization actions to be executed. For instance, adding a SortDescription to an ICollectionView object can cause the object to perform a sorting operation on the items it contains. When multiple modifications to an object are made, it is desirable to postpone these synchronization actions until all modifications are made.

This blog presents the PostponableAction class with which this kind of behavior can be implemented. This idea is based on and can be used as an implementation to the DeferRefresh method of the ICollectionView interface.

Introduction
Implementation
Usage
Download

Implementation

The heart of the PostponableAction class is made up of the inner class PostponableActionHelper. The purpose of this class is to perform an action when the instance is disposed. This class is implemented as follows:

private class PostponableActionHelper : IDisposable
{
    private Action _onDispose;
    private bool _disposed;
 
    public PostponableActionHelper(Action onDispose)
    {
        if (onDispose == null)
        {
            throw new ArgumentNullException("onDispose");
        }
        _onDispose = onDispose;
        _disposed = false;
    }
 
    ~PostponableActionHelper()
    {
        Dispose(false);
    }
 
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
 
    private void Dispose(bool disposing)
    {
        if (_disposed)
        {
            return;
        }
        _onDispose();
        _disposed = true;
    }
}

The PostponableAction is implemented as follows:

public class PostponableAction
{
    private Action _action;
    private int _postponeLevel;
    private bool _mustExecute;
    private Object _lockObject = new Object();
 
    public PostponableAction(Action action)
    {
        if (action == null)
        {
            throw new ArgumentNullException("action");
        }
        _action = action;
    }
 
    public void Execute()
    {
        lock (_lockObject)
        {
            if (_postponeLevel > 0)
            {
                _mustExecute = true;
                return;
            }
        }
        _action();
    }
 
    public IDisposable PostponeAction
    {
        get
        {
            lock (_lockObject)
            {
                _postponeLevel++;
            }
            return new PostponableActionHelper(OnDisposePostponableActionHelper);
        }
    }
 
    public bool IsPostponing
    {
        get
        {
            return _postponeLevel > 0;
        }
    }
 
    private void OnDisposePostponableActionHelper()
    {
        lock (_lockObject)
        {
            if (--_postponeLevel > 0 || !_mustExecute)
            {
                return;
            }
            _mustExecute = false;
        }
        _action();
    }
}

Some notes on the implementation of PostponableAction:

The implementation is thread safe
If Execute() has not been called during the lifetime of a PostponeAction object, the action will not be executed when this object is disposed.
If Execute() has been called during the lifetime of a PostponeAction object, the action will be executed once when the last PostponeAction object is disposed.

Usage

The following class gives a sample of the usage of PostponableAction:

public class Work
{
	private PostponableAction _synchronize = new PostponableAction(SynchronizeImplementation);
 
	private void SynchronizeImplementation()
	{
		// Some time consuming operations
	}
 
	public void Synchronize()
	{
		_synchronize.Execute();
	}
 
	public IDisposable PostponeSynchronize()
	{
		get
		{
			return _synchronize.PostponeAction;
		}
	}
 
 
	public void Operation1()
	{
		// Some operations followed by
 
		Synchronize();
	}
 
	public void Operation2()
	{
		// Some operations followed by
 
		Synchronize();
	}
 
	public void Operation3()
	{
		using (PostponeSynchronize)
		{
			Operation1();
			Operation2();
		}
	}
}

When Operation3 is called, the synchronization executed only once when the using block is exited.

Download

The source for the PostponableAction class can be downloaded here.

Synchronizing group row headers with column headers in Silverlight DataGrid

Emiel — Fri, 20 Aug 2010 09:32:58 +0000

Update

The code for the functionality in this post has been updated in Update postings on Datagrid

Grouping in the DataGrid in Silverlight is quite easy. What is not so obvious is how to change the caption of the column name on the group row. It turns out that you could use the LoadingRowGroup of the DataGrid:

theGrid.LoadingRowGroup += (s, e) =>
{
    e.RowGroupHeader.PropertyName = "A custom caption";
}

The original value of the e.RowGroupHeader.PropertyName is the PropertyName of the PropertyGroupDescription. Using this value the column header can be determined:

private string GetColumnCaption(DataGrid grid, string columnName)
{
    if (grid == null || String.IsNullOrEmpty(columnName))
    {
        return null;
    }
 
    foreach (DataGridBoundColumn column in grid.Columns)
    {
        if (column == null)
        {
            continue;
        }
        Binding binding = column.Binding;
        if (binding == null)
        {
            continue;
        }
        if (binding.Path.Path == columnName)
        {
            return Convert.ToString(column.Header);
        }
    }
 
    return null;
}

Using this function synchronizing the group row header with column headers becomes almost trivial:

theGrid.LoadingRowGroup += (s, e) =>
{
    string columnName = e.RowGroupHeader.PropertyName;
    string columnCaption = GetColumnCaption(sender as DataGrid, columnName);
 
    if (!String.IsNullOrEmpty(columnCaption))
    {
        e.RowGroupHeader.PropertyName = columnCaption;
    }
}

Other interesting properties of e.RowGroupHeader are:

PropertyNameVisibility: determines the visibility of the PropertyName
ItemCountVisibility: determines the visibility of the item count

The sourcecode for this blog can be found here.

Update

When the DataGrid is sorted, the group row headers display their old captions again. See this post for a possible solution.

INotifyPropertyChanged: automatic dependent property and nested object support

Emiel — Fri, 02 Jul 2010 15:05:25 +0000

Summary

The hardest problem with INotifyPropertyChanged is often overlooked: dependency management. When one property is changed, all of its dependent properties need to fire as well.

This blog presents another solution based on dynamic dependency determination.

Introduction
The problem
Solution
Implementation
Usage
Example
Download
Final words

Introduction

As stated by Michael L Perry in a comment on my blog INotifyPropertyChanged implementations: An Overview:

The hardest problem with INotifyPropertyChanged is often overlooked: dependency management. When one property is changed, all of its dependent properties need to fire as well.

Here are some solutions other people have come up with:

Michael L Perry created a solution based on Independent properties
Neil Mosafi also recognizes this problem in this blog post and Tomas Elison presented in this comment a solution based on attributes

This blog presents another solution based on dynamic dependency determination.

The problem

Introduction

There are two problems to solve:

How to generate INotifyPropertyChanged notifications for dependent properties
How to generate INotifyPropertyChanged notifications for nested object hierarchies

The following paragraphs give examples of both kind of problems.

Dependent properties

Suppose there is a Person class that contains the properties FirstName, LastName and the calculated property FullName. When for instance the first name of a person changes, obviously the full name also changes. This class could be implemented like this using the BindableObjectBase from this post:

public class Person : BindableObjectBase
{
    private string firstName;
    private string lastName;
 
    public Person(string firstName, string lastName)
    {
        this.FirstName = firstName;
        this.LastName = lastName;
    }
 
    public string FirstName
    {
        get
        {
            return this.firstName;
        }
        set
        {
            if (this.SetValue(ref this.firstName, value, "FirstName"))
            {
                this.OnPropertyChanged("FullName");
            }
        }
    }
 
    public string LastName
    {
        get
        {
            return this.lastName;
        }
        set
        {
            if (this.SetValue(ref this.lastName, value, "LastName"))
            {
                this.OnPropertyChanged("FullName");
            }
        }
    }
 
    public string FullName
    {
        get
        {
            return this.FirstName + " " + this.LastName;
        }
    }
}

The problem lies in the manual addition of the OnPropertyChanged calls. When classes get complex, it can be a nightmare to maintain.

Nested objects

Now suppose there is also a HelloMessage that is defined as follows:



public class HelloMessage : BindableObjectBase
{
    private Person person;
 
    public HelloMessage(Person person)
    {
        this.Person = person;
    }
 
    public Person Person
    {
        get
        {
            return this.person;
        }
        set
        {
            if (this.SetValue(ref this.person, value, "Person"))
            {
                this.OnPropertyChanged("Message");
            }
        }
    }
 
    public string Message
    {
        get
        {
            return "Hello " + this.Person.FullName;
        }
    }
}


Now this code



Person person = new Person("E", "Jongerius");
HelloMessage message = new HelloMessage(person);
message.PropertyChanged += (s, e) =>
{
    Console.WriteLine("* Changed: " + e.PropertyName);
};
 
// Display the message
Console.WriteLine(message.Message);
 
// Change first name
person.FirstName = "Emiel";
 
// Display the message again
Console.WriteLine(message.Message);



results in


Hello E Jongerius
Hello Emiel Jongerius


The message.PropertyChanged event is not raised, although the value of message.Message has been changed.


The usual way to approach this problem is to replace the definition of the Person property with the following:


public Person Person
{
    get
    {
        return this.person;
    }
    set
    {
        INotifyPropertyChanged oldValue = this.person as INotifyPropertyChanged;
        INotifyPropertyChanged newValue = value as INotifyPropertyChanged;
 
        if (this.SetValue(ref this.person, value, "Person"))
        {
            this.OnPropertyChanged("Message");
 
            if (oldValue != null)
            {
                oldValue.PropertyChanged -= this.OnPersonChanged;
            }
            if (newValue != null)
            {
                newValue.PropertyChanged += this.OnPersonChanged;
            }
        }
    }
}
 
private void OnPersonChanged(object s, PropertyChangedEventArgs e)
{
    this.OnPropertyChanged("Person");
    this.OnPropertyChanged("Message");
}


Again, this can result in a maintenance nightmare when object hierarchies become complex.

Solution

The basic idea of the solution described in this blog is that the base class keeps track of the dependencies between the properties. This information is determined dynamically at runtime, during the calls to the property getters. Whenever the value of a property is changed, the previously determined information is used to raise change notifications for dependent properties.


Also the property values are checked whether they implement the INotifyPropertyChanged interface. If so, the appropriate event handlers are attached and detached during the setting of the property. A similar strategy is used by Caliburn.


There are two important things to notice about this approach:

Dependencies are determined dynamically at runtime, so a performance hit is likely to be expected
Dependencies are updated only when property getters are called. This implies that when the value of a property has not been retrieved, the dependency information regarding this property has not been determined. Normally this would be no problem, because if the value of a property has not been used, the application is probably also not interested in the fact that the value of this property has been changed

Implementation
Base class

The solution uses the BindableObjectBase class from this post as the base class with the following modifications:

The function OnPropertyChanged(string propertyName) has been made virtual
The static function GetPropertyNameFromStackTrace() has been made protected
The static function GetPropertyNameFromExpression(Expression> property) has been made protected
Refactored the functions SetValue(ref T local, T newValue, Expression> property) and SetValue(ref T local, T newValue) to make use of the function SetValue(ref T local, T newValue, string propertyName)
The function SetValue(ref T local, T newValue, string propertyName) has been made virtual

Storage of dependency information

The dependency information is stored as follows:


private static IDictionary<string, IDictionary<string, ISet<string>>> globalPropertyDependencyCollection = new Dictionary<string, IDictionary<string, ISet<string>>>();
 
private IDictionary<string, ISet<string>> propertyDependencyCollection;
private IDictionary<string, ISet<string>> PropertyDependencyCollection
{
    get
    {
        if (this.propertyDependencyCollection == null)
        {
            if (!BindableObjectBase2.globalPropertyDependencyCollection.TryGetValue(this.GetType().FullName, out this.propertyDependencyCollection))
            {
                this.propertyDependencyCollection = new Dictionary<string, ISet<string>>();
                BindableObjectBase2.globalPropertyDependencyCollection[this.GetType().FullName] = this.propertyDependencyCollection;
            }
        }
        return this.propertyDependencyCollection;
    }
}


The private static variable globalPropertyDependencyCollection is used to reused dependency information between instances of the same type. Access to the global dependency information is cached using the propertyDependencyCollection instance variable.


Adding dependency information is relatively straight forward:


private void AddPropertyDependency(string property, string dependsOn)
{
    ISet<string> propertyDependencies = null;
    if (!this.PropertyDependencyCollection.TryGetValue(dependsOn, out propertyDependencies))
    {
        propertyDependencies = new HashSet<string>();
    }
    else
    {
        if (propertyDependencies.Contains(property))
        {
            return;
        }
    }
 
    propertyDependencies.Add(property);
 
    this.PropertyDependencyCollection[dependsOn] = propertyDependencies;
}

Notify changes

Based on the stored dependency information, change notifications regarding dependent properties can be automatically sent using this override to OnPropertyChanged:


protected override void OnPropertyChanged(string propertyName)
{
    base.OnPropertyChanged(propertyName);
 
    ISet<string> dependsOn = null;
    if (!this.PropertyDependencyCollection.TryGetValue(propertyName, out dependsOn))
    {
        return;
    }
 
    foreach (string item in dependsOn)
    {
        base.OnPropertyChanged(item);
    }
}

Property Get call stack

Before the actually dependencies can be determined, an additional piece of infrastructure has to be put in place. Whenever a property getter is called from within another getter, a dependency between these two properties must be added. To keep track of property getter calls, a call stack is implemented:


private Stack<string> getCallStack = new Stack<string>();


Based on the contents of this call stack, the dependencies can be added using the following function:


private void PropertyGetCalled(string propertyName)
{
    foreach (string p in this.getCallStack)
    {
        this.AddPropertyDependency(p, propertyName);
    }
}

Determining dependencies

In order to determine the dependencies the following private class is used:


private class PropertyTracker : IDisposable
{
    private bool isDisposed = false;
    private BindableObjectBase2 containingObject;
 
    public PropertyTracker(string propertyName, BindableObjectBase2 objectBase)
    {
        this.containingObject = objectBase;
        this.containingObject.PropertyGetCalled(propertyName);
        this.containingObject.getCallStack.Push(propertyName);
    }
 
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
 
    private void Dispose(bool disposing)
    {
        if (this.isDisposed)
        {
            return;
        }
 
        this.containingObject.getCallStack.Pop();
        this.containingObject = null;
        this.isDisposed = true;
    }
 
    ~PropertyTracker()
    {
        Dispose(false);
    }
}


This class serves two functions:

It calls the function PropertyGetCalled on the containing object, which adds the dependencies to dependent properties
It pushes the property name on the call stack and makes sure that the name is removed whenever the class gets disposed.

As long as for each property an instance of this class is created at the start of the getter and this instance is disposed at the end of the getter, the getCallStack will be filled correct and the correct references will be added using the call to PropertyGetCalled.


To facilitate the use of the class the following helper functions have been defined:


protected IDisposable GetPropertyTracker()
{
    return this.GetPropertyTracker(GetPropertyNameFromStackTrace());
}
 
protected IDisposable GetPropertyTracker<T>(Expression<Func<T>> property)
{
    return this.GetPropertyTracker(GetPropertyNameFromExpression(property));
}
 
protected IDisposable GetPropertyTracker(string propertyName)
{
    return new PropertyTracker(propertyName, this);
}

Nested object support

With the following additions it is possible to extend this solution to support nested objects:


private Dictionary<string, PropertyChangedEventHandler> propertyChangedEventHandlers = new Dictionary<string, PropertyChangedEventHandler>();
 
protected override bool SetValue<T>(ref T local, T newValue, string propertyName)
{
    INotifyPropertyChanged localAsBindableObject = local as INotifyPropertyChanged;
    INotifyPropertyChanged newValueAsBindableObject = newValue as INotifyPropertyChanged;
 
    if (!base.SetValue<T>(ref local, newValue, propertyName))
    {
        return false;
    }
 
    if (localAsBindableObject != null)
    {
        PropertyChangedEventHandler handler = null;
        if (propertyChangedEventHandlers.TryGetValue(propertyName, out handler))
        {
            this.propertyChangedEventHandlers.Remove(propertyName);
            localAsBindableObject.PropertyChanged -= handler;
        }
    }
 
    if (newValueAsBindableObject != null)
    {
        PropertyChangedEventHandler handler = (s, e) => { OnPropertyChanged(propertyName); };
 
        this.propertyChangedEventHandlers[propertyName] = handler;
        newValueAsBindableObject.PropertyChanged += handler;
    }
 
    return true;
}


The basic idea behind this code is that whenever a value of a property raises the PropertyChanged event, we can assume that that property has changed, so we can raise the PropertyChanged event for the object containing the property too. This is done  by attaching a PropertyChanged handler to all objects that support the INotifyPropertyChanged interface whenever they are used as a value of a property and to remove the handler whenever the property gets another value.

Preventing a PopertyChanged event storm

Executing this example with the base objects that implement the techniques described above, gives the following results:


* Changed: Person
* Changed: Message
* Changed: Person
* Changed: Message


The PropertyChanged event gets fired twice for each property. This is caused by the following chaing of events:


The statement peson.FirstName = "Emiel"; causes person.PropertyChanged("FirstName") to be raised, which causes

message.PropertyChanged("Person") to be raised, which causes message.PropertyChanged("Message") to be raised.
person.PropertyChanged("FullName") to be raised, which causes message.PropertyChanged("Person") to be raised, which causes message.PropertyChanged("Message") to be raised.


The solution to this problem is to reorder the generated PropertyChanged events  and remove the duplicates during the reordering. This strategy is implemented in the following class:


public class BindableObjectBase3 : BindableObjectBase2
{
    private static IDictionary<BindableObjectBase3, ISet<string>> delayedNotifications = null;
    private static BindableObjectBase3 currentObject = null;
 
    protected override void OnPropertyChanged(string propertyName)
    {
        bool isFirst = (delayedNotifications == null);
 
        try
        {
            if (isFirst)
            {
                delayedNotifications = new Dictionary<BindableObjectBase3, ISet<string>>();
                currentObject = this;
 
                base.OnPropertyChanged(propertyName);
            }
            else
            {
                if (this == currentObject)
                {
                    base.OnPropertyChanged(propertyName);
                }
                else
                {
                    this.OnPropertyChangedDelayed(propertyName);
                }
            }
        }
        finally
        {
            if (isFirst)
            {
                try
                {
                    ProcessDelayedNotifications();
                }
                finally
                {
                    delayedNotifications = null;
                    currentObject = null;
                }
            }
        }
    }
 
    private void OnPropertyChangedDelayed(string propertyName)
    {
        ISet<string> delayedNotificationsForThis = null;
 
        if (!delayedNotifications.TryGetValue(this, out delayedNotificationsForThis))
        {
            delayedNotificationsForThis = new HashSet<string>();
            delayedNotifications.Add(this, delayedNotificationsForThis);
        }
 
        delayedNotificationsForThis.Add(propertyName);
    }
 
    private void ProcessDelayedNotifications()
    {
        if (delayedNotifications == null)
        {
            return;
        }
 
        while (delayedNotifications.Any())
        {
            KeyValuePair<BindableObjectBase3, ISet<string>> firstItem = delayedNotifications.ElementAt(0);
            delayedNotifications.Remove(firstItem.Key);
 
            currentObject = firstItem.Key;
            foreach (string propertyName in firstItem.Value)
            {
                currentObject.OnPropertyChanged(propertyName);
            }
        }
    }
}

Usage

The solution presented in this post is easy to use:

Derive all business objects from BindableObjectBase3
Wrap all property getters with a using statement which contains a new instance of the PropertyTracker class created by one of the overloads of GetPropertyTracker
Use one of the overloads of SetValue in the property setters

That's it!

Example

This sample in this paragraph can also be found in the code download.


Note: in this example the strategy using lambda expressions and expression trees to determine the names of properties is used. All other strategies described here could be used too.

Class Person

public class Person : BindableObjectBase3
{
    private string firstName;
    private string lastName;
 
    public Person(string firstName, string lastName)
    {
        this.FirstName = firstName;
        this.LastName = lastName;
    }
 
    public string FirstName
    {
        get
        {
            using (this.GetPropertyTracker(() => this.FirstName))
            {
                return this.firstName;
            }
        }
            set
            {
                this.SetValue(ref this.firstName, value, () => this.FirstName);
            }
        }
 
        public string LastName
        {
            get
            {
                using (this.GetPropertyTracker(() => this.LastName))
                {
                    return this.lastName;
                }
            }
            set
            {
                this.SetValue(ref this.lastName, value, () => this.LastName);
            }
        }
 
    public string FullName
    {
        get
        {
            using (this.GetPropertyTracker(() => this.FullName))
            {
                return this.FirstName + " " + this.LastName;
            }
        }
    }
}

Class HelloMessage

public class HelloMessage : BindableObjectBase3
{
    private Person person;
 
    public HelloMessage(Person person)
    {
        this.Person = person;
    }
 
    public Person Person
    {
        get
        {
            using (this.GetPropertyTracker(() => this.Person))
            {
                return this.person;
            }
        }
        set
        {
            this.SetValue(ref this.person, value, () => this.Person);
        }
    }
 
    public string Message
    {
        get
        {
            using (this.GetPropertyTracker(() => this.Message))
            {
                return "Hello " + this.Person.FullName;
            }
        }
    }
}

Test

Person person1 = new Person("E.", "Jongerius");
 
person1.PropertyChanged += (s, e) =>
{
    Console.WriteLine(String.Format("   // Raised: person1.PropertyChanged(\"{0}\");", e.PropertyName));
};
 
HelloMessage message = new HelloMessage(person1);
 
message.PropertyChanged += (s, e) =>
{
    Console.WriteLine(String.Format("   // Raised: message.PropertyChanged(\"{0}\");", e.PropertyName));
};
 
person1.FirstName = "Emiel";
   // Raised: person1.PropertyChanged("FirstName");
   // Raised: message.PropertyChanged("Person");
 
// The following line causes the dependency information
// to be updated
string msg = message.Message;
 
person1.FirstName = "E.";
   // Raised: person1.PropertyChanged("FirstName");
   // Raised: person1.PropertyChanged("FullName");
   // Raised: message.PropertyChanged("Person");
   // Raised: message.PropertyChanged("Message");
 
Person person2 = new Person("Someone", "Else");
 
person2.PropertyChanged += (s, e) =>
{
    Console.WriteLine(String.Format("   // Raised: person2.PropertyChanged(\"{0}\");", e.PropertyName));
};
 
message.Person = person2;
   // Raised: message.PropertyChanged("Person");
   // Raised: message.PropertyChanged("Message");
 
person1.FirstName = "Emiel";
   // Raised: person1.PropertyChanged("FirstName");
   // Raised: person1.PropertyChanged("FullName");
 
person2.FirstName = "S.";
   // Raised: person2.PropertyChanged("FirstName");
   // Raised: person2.PropertyChanged("FullName");
   // Raised: message.PropertyChanged("Person");
   // Raised: message.PropertyChanged("Message");

Download

All sources can be downloaded here

Final words

The implementation given above has some limitations:

The implementation is not theadsafe
It is possible to create object hierarchies that cause endless loops during PropertyChanged events.



INotifyPropertyChanged implementations: An Overview
Emiel — Fri, 25 Jun 2010 14:58:07 +0000
Summary

One of the cornerstones of MVVM is the INotifyPropertyChanged interface. This post describes several implementations that have been used/proposed over time.

Table of contents


Introduction
Defacto standard
Using Lambda Expressions and Expression Trees
Using MethodBase.GetCurrentMethod()
Using StackTrace
Performance comparison
Other implementations

MSIL weaving
Using Proxy objects


Additional reading
Source download

Introduction
 One of the cornerstones of MVVM is the INotifyPropertyChanged interface. This post describes several implementations that have been used/proposed over time. 
 The basic ingredient of each INotifyPropertyChanged implementation is the declaration of the PropertyChanged event, and a function to raise this event. We will use the following: 

public class BindableObject
{
	public event PropertyChangedEventHandler PropertyChanged;
 
	protected void OnPropertyChanged(string propertyName)
        {
            PropertyChangedEventHandler handler = this.PropertyChanged;
            if (handler == null || String.IsNullOrWhiteSpace(propertyName))
            {
                return;
            }
 
            handler(this, new PropertyChangedEventArgs(propertyName));
        }
}


The challenge in implementing the interface is to get the proper value for the propertyName argument of the OnPropertyChanged in a re-factor-friendly way.

Defacto standard

The typical defacto standard way of implementing a property is the following:


private string useString;
 
public string UseString
{
	get
	{
		return this.useString;
	}
	set
	{
		if (Object.Equals(this.useString, value))
		{
			return;
		}
		this.useString = value;
 
		OnPropertyChanged("UseString");
	}
}


The code in the setter is sometimes re-factored using a generic function like this:


protected bool SetValue<T>(ref T property, T value, string propertyName)
{
	if (Object.Equals(property, value))
	{
		return false;
	}
	property = value;
 
	OnPropertyChanged(propertyName);
 
	return true;
}


to this:


public string UseString
{
	get
	{
		return this.useString;
	}
	set
	{
		SetValue(ref this.useString, value, "UseString");
	}
}


This solution is not re-factor friendly: when you change the name of the property, you also have to change manually the string containing the name of the property. Failing to do this, does not lead to compiler errors, but will certainly lead to bugs that are difficult to track down. To tackle this problem the propertyName parameter of the function OnPropertyChanged Josh Smith proposed using the following function:


[Conditional("DEBUG")]
private void VerifyProperty(string propertyName)
{
	Type type = this.GetType();
 
	// Look for a public property with the specified name.
	PropertyInfo propInfo = type.GetProperty(propertyName);
 
	Debug.Assert(propInfo != null, string.Format(CultureInfo.InvariantCulture, "{0} is not a property of {1}", propertyName, type.FullName));
}


This leads to the following implementation of OnPropertyChanged:


protected void OnPropertyChanged(string propertyName)
{
	VerifyProperty(propertyName);
 
	PropertyChangedEventHandler handler = this.PropertyChanged;
        if (handler == null || String.IsNullOrWhiteSpace(propertyName))
        {
        	return;
	}
 
	handler(this, new PropertyChangedEventArgs(propertyName));
}


This approach will not lead to compile-time errors when the string containing the property name does not match the actual property name, but it will raise an assertion error in debug builds when OnPropertyChanged is called with non existent property names. However, this approach fails when the a wrong name is used of a property that does exist in the class. For example:


private string property1;
private string property2;
 
public string Property1
{
	get { return this.property1; }
	set { SetValue(ref this.property1, value, "Property1"); }
}
 
public string Property2
{
	get { return this.property2; }
	set { SetValue(ref this.property2, value, "Property1"); }
}


When copy/paste programming is used, this is likely to happen.

Using Lambda Expressions and Expression Trees

Refactor friendly INotifyPropertyChanged implementations like this use Lambda Expressions and Expression Trees to determine the property name using a function like this:


public static string GetPropertyNameFromExpression<T>(Expression<Func<T>> property)
{
	var lambda = (LambdaExpression)property;
	MemberExpression memberExpression;
 
	if (lambda.Body is UnaryExpression)
	{
		var unaryExpression = (UnaryExpression)lambda.Body;
                memberExpression = (MemberExpression)unaryExpression.Operand;
	}
	else
	{
		memberExpression = (MemberExpression)lambda.Body;
	}
 
	return memberExpression.Member.Name;
}


with which the following implementation of OnPropertyChanged can be defined:


protected void OnPropertyChanged<T>(Expression<Func<T>> property)
{
	OnPropertyChanged(GetPropertyNameFromExpression(property));
}


Now we can implement a property as follows:


private string useDelegate;
 
public string UseDelegate
{
	get
	{
		return this.useDelegate;
	}
	set
	{
		if (Object.Equals(this.useDelegate, value))
		{
			return;
		}
		this.useDelegate = value;
 
		OnPropertyChanged(() => UseDelegate);
	}
}


or with the following definition of SetValue


protected bool SetValue<T>(ref T property, T value, Expression<Func<T>> propertyDelegate)
{
	if (Object.Equals(property, value))
	{
		return false;
	}
	property = value;
 
	OnPropertyChanged(propertyDelegate);
 
	return true;
}


we can rewrite the property definition as follows:


public string UseDelegate
{
	get
	{
		return this.useDelegate;
	}
	set
	{
		SetValue(ref this.useDelegate, value, () => UseDelegate);
	}
}


The upside of this approach is, that it is re-factor friendly: whenever the name of the property is re-factored using a re-factor-tool, the delegate is re-factored too and the correct property name is used in the PropertyChanged event. Another advantage is that misspellings lead to compiler errors, so there is no need for the VerifyProperty function. On the downside: due to the use of reflection, you can experience a performance hit. Furthermore: this approach is also vulnerable to bugs introduced by copy/paste programming like this:


private string property1;
private string property2;
 
public string Property1
{
	get { return this.property1; }
	set { SetValue(ref this.property1, value, () => Property1); }
}
 
public string Property2
{
	get { return this.property2; }
	set { SetValue(ref this.property2, value, () => Property1); }
}


On a personal note: I do not like the way this approach looks in code. It has some code smell about it.

Using MethodBase.GetCurrentMethod()

Karl Shifflett took another road in this article: he proposed to get the property name from using MethodBase.GetCurrentMethod(). This leads to the following implementation of a property:


public string UseMethodBase
{
	get
	{
		return this.useString;
	}
	set
	{
		SetValue(ref this.useString, value, MethodBase.GetCurrentMethod().Name.Remove(0,4));
	}
}


This solution works quite well, although in his article Karl states:

There could be issues with reliability of reflection for production environment where assemblies can be obfuscated, delayed signed etc.

So probably when using this method, it is wise to leave the VerifyProperty function in place.


Because this approach is based upon reflection too, a performance hit is to be expected. Furthermore it is impossible to re-factor the call to MethodBase.GetCurrentMethod() into a helper function, so when using this approach you are stuck using the call to MethodBase.GetCurrentMethod().Name.Remove(0,4) in every property setter.

Using StackTrace

Important note: the following approach will not work in optimized release builds, so this approach is probably not suited for production code. This approach is included because it shows a very clean interface.


Using the StackTrace class we could determine the name of the property setter using the following function:


private static string GetPropertyNameFromStackTrace()
{
	StackTrace stackTrace = new StackTrace();           // get call stack
        StackFrame[] stackFrames = stackTrace.GetFrames();  // get method calls (frames)
 
	foreach (StackFrame stackFrame in stackFrames)
        {
		string name = stackFrame.GetMethod().Name;
 
		if (name.StartsWith("set_", StringComparison.Ordinal))
                {
			return name.Substring(4);
                }
	}
 
	string s = "";
	foreach (StackFrame stackFrame in stackFrames)
	{
		s += "   " + stackFrame.GetMethod().Name + Environment.NewLine;
	}
	throw new Exception("Could not determine property name. StackTrace:\n" + s);
}


With this we could create the following implementation of OnPropertyChanged:


protected void OnPropertyChanged()
{
	OnPropertyChanged(GetPropertyNameFromStackTrace());
}


The property implementation would become


private string useStackTrace;
 
public string UseStackTrace
{
	get
	{
		return this.useStackTrace;
	}
	set
	{
		if (Object.Equals(this.useStackTrace, value))
		{
			return;
		}
		this.useStackTrace = value;
 
		OnPropertyChanged();
	}
}


or with the following definition of SetValue


protected bool SetValue<T>(ref T property, T value)
{
	if (Object.Equals(property, value))
	{
		return false;
	}
	property = value;
 
	OnPropertyChanged();
 
	return true;
}


we can rewrite the property definition as follows:


public string UseStackTrace
{
	get
	{
		return this.useStackTrace;
	}
	set
	{
		SetValue(ref this.useStackTrace, value);
	}
}


From a development point of view, this is a very neat solution. But unfortunately the documentation of StackTrace states that Stacktrace might not report as many method calls as expected, due to code transformations that occur during optimization. For this approach to work at least the following must be true:

The name of the property setter must not be mangled for instance by by obfuscation
The setter must not be in-lined


According to this article written in 2004, we can prevent in-lining of the setter by applying the MethodImpl attribute like this:


public string UseStackTrace
{
	get
	{
		return this.useStackTrace;
	}
	[MethodImpl(MethodImplOptions.NoInlining)]
	set
	{
		SetValue(ref this.useStackTrace, value);
	}
}


Unfortunately having to apply this attribute to every setter takes away some of the neatness of this solution.

Performance comparison

Below is the output of a performance test run. The run is made with an optimized release build a release build, without any .pdb files, running from the command line running on Windows 7 in a virtual machine running on Windows XP. The PropertyChanged event handler contained some mathematical calculations to a simulate the actions that are usually performed in the event handler. The source code of the test can be found here.


1     times using                 UseString => 1,9531 ms
1     times using         UseStringVerified => 0 ms
1     times using             UseMethodBase => 0,9766 ms
1     times using     UseMethodBaseVerified => 0 ms
1     times using             UseExpression => 0 ms
1     times using     UseExpressionVerified => 0 ms
1     times using             UseStackTrace => 0 ms
1     times using     UseStackTraceVerified => 0 ms
 
501   times using                 UseString => 83,9844 ms
501   times using         UseStringVerified => 88,8672 ms
501   times using             UseMethodBase => 92,7734 ms
501   times using     UseMethodBaseVerified => 85,9375 ms
501   times using             UseExpression => 80,0781 ms
501   times using     UseExpressionVerified => 78,125 ms
501   times using             UseStackTrace => 92,7735 ms
501   times using     UseStackTraceVerified => 88,8671 ms
 
1001  times using                 UseString => 155,2734 ms
1001  times using         UseStringVerified => 153,3203 ms
1001  times using             UseMethodBase => 157,2265 ms
1001  times using     UseMethodBaseVerified => 157,2266 ms
1001  times using             UseExpression => 160,1563 ms
1001  times using     UseExpressionVerified => 164,0625 ms
1001  times using             UseStackTrace => 175,7812 ms
1001  times using     UseStackTraceVerified => 172,8515 ms
 
1501  times using                 UseString => 226,5625 ms
1501  times using         UseStringVerified => 227,5391 ms
1501  times using             UseMethodBase => 246,0938 ms
1501  times using     UseMethodBaseVerified => 248,0469 ms
1501  times using             UseExpression => 264,6485 ms
1501  times using     UseExpressionVerified => 246,0937 ms
1501  times using             UseStackTrace => 258,7891 ms
1501  times using     UseStackTraceVerified => 262,6953 ms
 
2001  times using                 UseString => 299,8047 ms
2001  times using         UseStringVerified => 296,875 ms
2001  times using             UseMethodBase => 339,8437 ms
2001  times using     UseMethodBaseVerified => 355,4688 ms
2001  times using             UseExpression => 300,7812 ms
2001  times using     UseExpressionVerified => 325,1953 ms
2001  times using             UseStackTrace => 343,75 ms
2001  times using     UseStackTraceVerified => 388,6718 ms


Although we can conclude that using reflection incurs a performance hit, this hit is not as dramatic as expected: much less than 0.1 ms per event. This difference will not be noticeable for normal, Silverlight (business) applications, in which normally two to ten property changed events are raised. On the other hand, I agree with Karl Shifflett: If you have an application that has 100′s of events per second or more like real-time graphing applications, I would not use this method for performance reasons.  Instead, go with string constants for the property names or double quoted strings if you like that better.

Other strategies
MSIL weaving
Justin Angel has created a solution that implements INotifyPropertyChanged by injecting the necessary code in the property setters using Mono.Cecil as well as PostSharp 1.5. Gael Fraiteur has created a PostSharp 2.0 version. Simon Cropp created NotifyPropertyWeaver based on the Mono.Cecil implementation of Justin Angel.

Using Proxy objects

Einar Ingebrigtsen has proposed an implementation based on proxy objects. The downside of using this approach is that the classes cannot be instantiated using the keyword new anymore.


Ray Houston used a similar approach here and Jonas Follesø did something similar too.

Using Aspect Oriented Programming

Sacha Barber has implemented the INotifyPropertyChanged interface using 4 different Aspect Oriented Programming techniques which can be found in this well written article.

Additional reading

The following links may be helpful:

A base class which implements INotifyPropertyChanged
Updated – INotifyPropertyChanged – How to remove the Property Name String Code Smell
INotifyPropertyChanged: automatic dependent property and nested object support

Source download
The sources for this article can be downloaded here.



Silverlight DataContext Changed Event and Trigger
Emiel — Wed, 16 Jun 2010 11:38:02 +0000
Silverlight does not provide a DataContextChanged event. Several solutions have been created for this problem. The solution presented here is based on two attached properties instead of one. The advantage of this solution is that multiple event handlers can be attached and this solution does not force the developer to implement a specific interface like the solution presented here.
The heart of the solution consists of the static class DataContextChangedHelper. This class uses the attached property named InheritedDataContext which is bound to the DataContext of the FrameworkElement. Whenever the DataContext is changed, the value of InheritedDataContext (due to the binding) and as a result of that the function OnInheritedDataContextChanged is called. This function call the eventhandlers that are stored in the attached property DataContextChangedHandler.
The public interface of the DataContextChangedHelper consists of the following extension methods to the class FrameworkElement:

AddDataContextChangedHandler
RemoveDataContextChangedHandler

These methods take care of creating and destroying the attached properties.
The class DataContextChangedHelper is defined as follows:

public static class DataContextChangedHelper
{
    /// 
    /// Identifies the InheritedDataContext DependencyProperty.
    /// 
    private static readonly DependencyProperty InheritedDataContextProperty =
        DependencyProperty.RegisterAttached(
            "InheritedDataContext",
            typeof(object),
            typeof(DataContextChangedHelper),
            new PropertyMetadata(null, OnInheritedDataContextChanged));
 
    /// 
    /// Handles changes to the InheritedDataContext DependencyProperty.
    /// 
    /// Instance with property change.
    /// Property change details.
    private static void OnInheritedDataContextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        EventHandler handler = d.GetValue(DataContextChangedHandlerProperty) as EventHandler;
        if (handler!=null)
        {
            handler(d,EventArgs.Empty);
        }
    }
 
    /// 
    /// Identifies the DataContextChangedHandler DependencyProperty.
    /// 
    private static readonly DependencyProperty DataContextChangedHandlerProperty =
        DependencyProperty.RegisterAttached(
            "DataContextChangedHandler",
            typeof(EventHandler),
            typeof(DataContextChangedHelper),
            null);
 
    /// 
    /// Adds the data context changed handler.
    /// 
    /// Element to which the handler is added
    /// The handler to add
    public static void AddDataContextChangedHandler(this FrameworkElement element, EventHandler handler)
    {
        if (element==null || handler==null)
        {
            return;
        }
 
        if (element.GetValue(InheritedDataContextProperty) == null)
        {
            element.SetBinding(InheritedDataContextProperty, new Binding());
        }
 
        EventHandler currentHandler = (EventHandler)element.GetValue(DataContextChangedHandlerProperty);
        currentHandler += handler;
        element.SetValue(DataContextChangedHandlerProperty, currentHandler);
    }
 
    /// 
    /// Removes the data context changed handler.
    /// 
    /// The element from which the handler has to be removed
    /// The handler to remove
    public static void RemoveDataContextChangedHandler(this FrameworkElement element, EventHandler handler)
    {
        if (element == null || handler == null)
        {
            return;
        }
 
        EventHandler currentHandler = (EventHandler)element.GetValue(DataContextChangedHandlerProperty);
        currentHandler -= handler;
        if (currentHandler == null)
        {
            element.ClearValue(DataContextChangedHandlerProperty);
            element.ClearValue(InheritedDataContextProperty);
        }
        else
        {
            element.SetValue(DataContextChangedHandlerProperty, currentHandler);
        }
    }
}

Based on the class DataContextChangedHelper a trigger for use in Expression Blend can be defined as follows:

public class DataContextChangedTrigger : TriggerBase<FrameworkElement>
{
    /// 
    /// Called after the trigger is attached to an 
    /// 
    protected override void OnAttached()
    {
        base.OnAttached();
 
        this.AssociatedObject.AddDataContextChangedHandler(OnDataContextChanged);
    }
 
    /// 
    /// Called when the trigger is being detached from its , but before it has actually occurred
    /// 
    protected override void OnDetaching()
    {
        base.OnDetaching();
 
        this.AssociatedObject.RemoveDataContextChangedHandler(OnDataContextChanged);
    }
 
    /// 
    /// Called when the DataContext of the  is changed
    /// 
    /// 
    /// 
    private void OnDataContextChanged(object s, EventArgs e)
    {
        this.InvokeActions(this.AssociatedObject.DataContext);
    }
}

This trigger can be used as follows:


    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
    xmlns:my="clr-namespace:TriggerTest">
 
    >
        >
            
        >
    >
 
    ...
>

The code for this post including a sample project can be found here.



Localization of XAML files in Silverlight
Emiel — Thu, 10 Jun 2010 13:49:19 +0000
This post describes a walk-through of the steps to perform in order to localize XAML files in Silverlight. This post is based on Silverlight 4, but all the steps do also apply to Silverlight 3. The full source code of the resulting project can be downloaded here. The language C# is used throughout this post, but the steps are easy translatable to VB.NET.
First create a Silverlight application solution using Visual Studio 2010 named LocalizationWalkThrough and close the solution after it has been created. Now open the project file LocalizationWalkThrough\LocalizationWalkThrough.csproj with your favorite text editor, and locate the tag SupportedCultures. Add a comma separated list of the cultures that the application has to support to this tag:

 version="1.0" encoding="utf-8"?>
 ...>
    >
        ...
        >en,nl>
        ...
    >
    ...
>

In this example we will use en as the default culture and nl as an additional culture. Next add a resource file to the project for the default culture and one for each additional culture:

and populate the resource files:

Set the custom tool for the resource of the default culture to PublicResourceCodeGenerator:

The custom tool PublicResourceCodeGenerator is part of the code generators by Guy Smith Ferrier. A VS2010 installer can be found here.
Changing the custom tool to PublicResourceCodeGenerator has the following effects:

The generated class for the resources will be public instead of internal
The constructor for the generated class will be public instead of internal

The next step is to add the resources to the application resources:

 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
             x:Class="LocalizationWalkThrough.App"
             xmlns:res="clr-namespace:LocalizationWalkThrough.Resources"
             >
    >
         x:Name="Strings" />
    >
>

We can now use the resources in XAML:

 x:Class="LocalizationWalkThrough.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
 
     x:Name="LayoutRoot" Background="White">
         Text="{Binding HelloWorld,Source={StaticResource Strings}}" />
    >
>

The final thing left to do is to add a feature for changing the culture. There a numerous possibilities to do this. Here the method of specifying the culture in the querystring of the containing page is used as described here:

private void Application_Startup(object sender, StartupEventArgs e)
{
    // Get the ui culture
    string culture;
    if (HtmlPage.Document.QueryString.TryGetValue("culture", out culture))
    {
        if (!String.IsNullOrWhiteSpace(culture))
        {
            try
            {
                // Set the correct UI culture
                Thread.CurrentThread.CurrentUICulture = new CultureInfo(culture);
            }
            catch
            {
                // Ignore any errors. We will just continue with the default culture
            }
        }
    }
 
    this.RootVisual = new MainPage();
}

And here is the result:

As a final optimization the following line could be added to the AssemblyInfo.cs file in the Properties directory:

[assembly: NeutralResourcesLanguageAttribute("en")]

This line informs the ResourceManager of the neutral culture of an assembly. Look here for more details.
The full source code of this walk through can be downloaded here.