I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

One Way Converters

Although the following paragraph doesn’t describe a new feature of the PDFx, it demonstrates a use case that solves a common problem developers face every day, apart from the sole monitoring of large Property Dependency networks.

The source code of the following example can be found in ViewModel ConverterDemonstrationVM which is part of the WPFSample’s source code.

In Two Way Converters I argue that value converters should be used exclusively to convert business domain data to UI specific data rather than to solely transform business domain data. I also showed how the PDFx can be employed to render two-way value converters, which convert domain data, redundant. The very same pattern can be applied to mimic the behavior of one way value converters in your ViewModel:

class ViewModel : BindableExt
{
	private Model Model { get; set; }

	public string MoneyQuantification
	{
		get
		{
			Property(() => MoneyQuantification)
				.Depends(p => p.On(Model, k => k.MoneyInEuros));

			if (Model.MoneyInEuros < 0)
			{
				return "Not too much";
			}

			if (Model.MoneyInEuros < 1000)
			{
				return "A Little";
			}

			if (Model.MoneyInEuros < 10000)
			{
				return "Quite some";
			}

			return "A Lot";
		}
	}
}

class Model : BindableExt
{
	private double _moneyInEuros = 100;
	public double MoneyInEuros
	{
		get { return _moneyInEuros; }
		set
		{
			_moneyInEuros = value;
			NotifyPropertyChanged(() => MoneyInEuros);
		}
	}
}

In this scenario, the PDFx ensures that the MoneyQuantification Property gets reevaluated whenever the Model’s MoneyInEuros Property changes.

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Two Way Converters

Although the following paragraph doesn’t describe a new feature of the PDFx, it demonstrates a use case that solves a common problem developers face every day, apart from the sole monitoring of large Property Dependency networks.

The source code of the following example can be found in ViewModel ConverterDemonstrationVM which is part of the WPFSample’s source code.

Oftentimes developers use value converters to transform domain-specific data into other domain-specific data (e.g. convert a money value from one currency to another), and thereby scatter conversion business logic throughout the project by implementing it in various different converters (that technically belong to the UI layer). The reason for this typical behavior is simple: comfort. value converters get automatically reevaluated as soon as the input data changes and therefore they are an easy tool to display up-to-date transformed data in the UI.
From my point of view, however, value converters should be used mainly to convert domain-specific data to UI-specific data (e.g. convert a bool from the ViewModel to a Visibility for the View). All the massaged data, which eventually ends up in the View, should be exposed by the ViewModel. This way a new View could easily be plugged into the existing ViewModel and business logic is executed before it reaches the View layer.

The PDFx allows you to enjoy the comfort of value converters (automatic reevaluation) within your ViewModels.

As explained in Data Delegation, the PDFx can be used to expose Model-data in the ViewModel.
The implementation of the MoneyInUSD-Property shows that the data doesn’t have to be delegated as is but can easily be transformed on the fly:

class ViewModel : BindableExt
{
	private Model Model { get; set; }

	public double MoneyInUSD
	{
		get
		{
			Property(() => MoneyInUSD)
				.Depends(p => p.On(Model, k => k.MoneyInEuros));

			return Model.MoneyInEuros * 1.3;
		}
		set { Model.MoneyInEuros = value / 1.3; }
	}
}

class Model : BindableExt
{
	private double _moneyInEuros = 100;
	public double MoneyInEuros
	{
		get { return _moneyInEuros; }
		set
		{
			_moneyInEuros = value;
			NotifyPropertyChanged(() => MoneyInEuros);
		}
	}
}

In this scenario, the PDFx ensures that the MoneyInUSD Property gets reevaluated whenever the Model’s MoneyInEuros Property changes.

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Simple Data Delegation

Although the following paragraph doesn’t describe a new feature of the PDFx, it demonstrates a use case that solves a common problem developers face every day, apart from the sole monitoring of large Property Dependency networks.

The source code of the following example can be found in ViewModel ConverterDemonstrationVM which is part of the WPFSample’s source code.

More often than not, ViewModels wrap one or more instances of the Model Layer. Purists (like me) prefer to bind View-controls only to properties that come directly from the ViewModel layer rather than also to properties that come from the Model layer. This way they decouple their Model from the View and create a true MVVM architecture.
This approach, however, means that every Model-value the View eventually would like to display needs to be exposed by the ViewModel.

Let’s look at the following ViewModel implementation which wraps a Model and delegates its properties:

class ViewModel
{
	private Model Model { get; set; }

	public double MoneyInEuros
	{
		get { return Model.MoneyInEuros; }
		set { Model.MoneyInEuros = value; }
	}
}

class Model : BindableExt
{
	private double _moneyInEuros = 100;
	public double MoneyInEuros
	{
		get { return _moneyInEuros; }
		set
		{
			_moneyInEuros = value;
			NotifyPropertyChanged(() => MoneyInEuros);
		}
	}
}

The problem with this purist approach is, however, that the data might change often directly in the Model layer without having passed through the ViewModel layer.
In the example above, the Model could represent an instance from a database. A service could now monitor the database and automatically reflect any changes that are applied to the database in the Model’s instance. Obviously, the ViewModel would not know about this change unless it explicitly monitors the PropertyChanged event of the Model instance.

This problem can easily be solved by employing the PDFx:

class ViewModel : BindableExt
{
	private Model Model { get; set; }

	public double MoneyInEuros
	{
		get
		{
			Property(() => MoneyInEuros)
				.Depends(p => p.On(Model, k => k.MoneyInEuros));

			return Model.MoneyInEuros;
		}
		set { Model.MoneyInEuros = value; }
	}
}

class Model : BindableExt
{
	private double _moneyInEuros = 100;
	public double MoneyInEuros
	{
		get { return _moneyInEuros; }
		set
		{
			_moneyInEuros = value;
			NotifyPropertyChanged(() => MoneyInEuros);
		}
	}
}

In this scenario, the PDFx would automatically propagate the MoneyInEuros Property’s changes of the Model layer to the ViewModel layer.

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Sanity Checks

Please refer to Library Versions to find out whether your platform specific PDFx version supports Sanity Checks.

In Debug mode, the PDFx performs certain resource expensive Sanity Checks that try to capture typical developer mistakes that are not caught at compile time.

Both the BindableExt’s Property and CachedValue methods ensure that the Property that is being pointed to in the first method parameter equals the Property from which either method is being called.

In the following example, the PDFx notices upon first access of the properties DependentPropertyMistake and CachedPropertyMistake that the way they use the PDFx is incorrect.

class WrongPDFXUsageDemonstration : BindableExt
{
	private int _inputValue;
	public int InputValue
	{
		get { return _inputValue; }
		set
		{
			_inputValue = value;
			NotifyPropertyChanged(() => InputValue);
		}
	}

	public int DependentPropertyMistake
	{
		get
		{
			Property(() => InputValue) //Should point to DependentPropertyMistake
				.Depends(p => p.On(() => InputValue));

			return InputValue*2;
		}
	}

	public int DependentPropertyProper
	{
		get
		{
			Property(() => DependentPropertyProper)
				.Depends(p => p.On(() => InputValue));

			return InputValue * 2;
		}
	}

	public int CachedPropertyMistake
	{
		get
		{
			return CachedValue(() => InputValue, () => InputValue * 5);
			//Should point to CachedPropertyMistake
		}
	}

	public int CachedPropertyProper
	{
		get
		{
			return CachedValue(() => CachedPropertyProper, () => InputValue * 5);
		}
	}
}

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Callbacks

When a source property changes, the PDFx allows you not only to automatically fire the PropertyChanged event for dependent properties, but also to execute callbacks in numerous scenarios.

The registration API for callbacks is not declarative, as the Property Dependency Registration API is, but rather imperative. Furthermore, the registration should not take place within a Property Getter but rather within a dedicated Registration method, as the following examples show.

Callbacks on Property Changes

The following example demonstrates how you can register Callbacks for normal Property Changes:

class SimpleCallbackExample : BindableExt
{
	public SimpleCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(Property1, OnProperty1Changed);
	}

	private void OnProperty1Changed()
	{
		Debug.WriteLine("Property1 has changed!");
	}

	private AnyType _property1;
	public AnyType Property1
	{
		get { return _property1; }
		set
		{
			_property1 = value;
			NotifyPropertyChanged(() => Property1);
		}
	}
}

The used overload of RegisterCallbackDependency expects you to pass in the owner of a property as the first parameter, a delegate that points to the Property that is to be monitored as the second parameter and finally a pointer to the callback that is supposed to be executed when the Property changes.

In the example above, OnProperty1Changed will be executed by the PDFx whenever Property1 changes.

Callbacks on Objects

The following example demonstrates how you can register one callback for all Property Changes of an object:

class ObjectCallbackExample : BindableExt
{
	public ObjectCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(this, OnAnyPropertyChanged);
	}

	private void OnAnyPropertyChanged()
	{
		Debug.WriteLine("Any Property has changed!");
	}

	private AnyType _property1;
	public AnyType Property1
	{
		get { return _property1; }
		set
		{
			_property1 = value;
			NotifyPropertyChanged(() => Property1);
		}
	}

	private AnyType _property2;
	public AnyType Property2
	{
		get { return _property2; }
		set
		{
			_property2 = value;
			NotifyPropertyChanged(() => Property2);
		}
	}
}

The used overload of RegisterCallbackDependency expects you to pass in a property owner that is to be monitored as the first parameter and a pointer to the callback that is supposed to be executed when any Property changes as the second parameter.

In the example above, OnAnyPropertyChanged will be executed by the PDFx whenever Property1 or Property2 changes.

Callbacks on Collections’ children

The PDFx also allows you to register callbacks that are to be fired when a specific property of an ObservableCollection’s child changes:

class CollectionPropertyCallbackExample : BindableExt
{
	private DependencyFrameworkObservableCollection<Child> _children 
		= new DependencyFrameworkObservableCollection<Child>();

	public CollectionPropertyCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(_children, k => k.Property1, OnCollectionChildPropertyChanged);
	}

	private void OnCollectionChildPropertyChanged()
	{
		Debug.WriteLine("Property1 of a child has changed!");
	}

	private class Child : BindableExt
	{
		private AnyType _property1;
		public AnyType Property1
		{
			get { return _property1; }
			set
			{
				_property1 = value;
				NotifyPropertyChanged(() => Property1);
			}
		}
	}
}

The first parameter of this RegisterCallbackDependency overload expects the collection that is to be monitored. The second parameter is to point to the Children’s Property that is of interest. The third parameter finally points to the callback that is to be executed.

In the example above, the method OnCollectionChildPropertyChanged will get fired whenever Property1 of any child changes.

Callbacks on entire Collections

The PDFx also allows to register callbacks that get executed whenever any child’s property changes or a child gets added or removed:

class CollectionCallbackExample : BindableExt
{
	private DependencyFrameworkObservableCollection<Child> _children
		= new DependencyFrameworkObservableCollection<Child>();

	public CollectionCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(_children, OnCollectionChanged);
	}

	private void OnCollectionChanged()
	{
		Debug.WriteLine("Collection has changed!");
	}

	private class Child : BindableExt
	{
		private AnyType _property1;
		public AnyType Property1
		{
			get { return _property1; }
			set
			{
				_property1 = value;
				NotifyPropertyChanged(() => Property1);
			}
		}

		private AnyType _property2;
		public AnyType Property2
		{
			get { return _property2; }
			set
			{
				_property2 = value;
				NotifyPropertyChanged(() => Property2);
			}
		}
	}
}

The first parameter of the used RegisterCallbackDependency overload expects the ObservableCollection that is to be monitored. The second parameter points to the callback.

PDFx will automatically execute the callback whenever any property of a child changes and whenever the collection itself is modified either by adding or by removing a child.

Deferred Callbacks

Please refer to Library Versions to find out whether the platform specific version of PDFx that you are using supports “Deferred Callbacks”

All the RegisterCallbackDependency overloads that are described in the paragraphs above are also available with the method RegisterDeferredCallbackDependency that allows you to register deferred callbacks.
If you register deferred callbacks, the execution of the callback is deferred by a certain amount of time (by default 100ms). Furthermore, if the callback trigger (such as a Property change) fires again before the wait time threshold has passed, the wait timer is reset. This feature gets especially useful when your callback is rather resource expensive and the underlying trigger might fire multiple times in a row.

Let’s look at the following example:

class SimpleCallbackExample : BindableExt
{
	public SimpleCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterDeferredCallbackDependency(this, k => SliderValue, SubmitDataToServer);
	}

	private void SubmitDataToServer()
	{
		Debug.WriteLine("Expensive call to submit data to server...");
	}

	private int _sliderValue;
	public int SliderValue
	{
		get { return _sliderValue; }
		set
		{
			_sliderValue = value;
			NotifyPropertyChanged(() => SliderValue);
		}
	}
}

In the example above, the SliderValue property could be bound to a slider. The requirement is to submit the slider’s new value to a server as soon as the user changes value. However, since a server call is rather expensive, the value should not be submitted while the user is still changing the value but rather as soon as the user finishes the change operation.
Such a requirement can easily be implemented by employing deferred callbacks as shown above.

Extensive Example

Please refer to WPFSample’s CallbacksDemonstrationVM to explore an example that makes heavy usage of the callback features.

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Smart Property Changed Notification

Whenever a property changes in a property dependency network, the PDFx can optionally first analyze all the property dependencies and then fire the INotifyPropertyChanged.PropertyChanged event only once for every directly or indirectly dependent property. This analysis saves tremendous amounts of precious CPU time since every PropertyChanged event causes your UI layer to access and thereby reevaluate the bound properties.

Usage

By default, the smart property changed notification is turned on.
If you have a reason to switch this behavior off, you can set the Bindable class’s UseSmartPropertyChangedNotificationByDefault Property to false.

Performance Demonstration

The source code of this example can be found in ViewModel SmartPropertyDependencyVM which is part of the WPFSample’s source code.

Let us look at the following object graph:

Green circles stand for Input Properties while purple circles indicate calculated properties. The arrows show the underlying math operations as well as the property dependencies.

The number next to the lightning icon indicates how often the INotifyPropertyChanged.PropertyChanged event has fired since the D1 Property has changed the last time.

A change of D1 results in the following:

As the picture indicates, INotifyPropertyChanged.PropertyChanged is fired only once for every single property for maximum performance.

When the Smart Property Change Notification is switched off, a change of D1 results in the following:

In this scenario, the PDFx does not analyze the Property Dependency Network before INotifyPropertyChanged.PropertyChanged events are fired but rather blindly performs a depth-search traversal down the dependency tree along all directly and indirectly dependent properties and fires INotifyPropertyChanged.PropertyChanged for every single property it finds. As shown above, this behavior results in 10 PropertyChanged Notifications for the root node, A1.

To be more specific, the PDFx traverses the tree in the following manner, if smart property change notification is switched off:

D1 -> C1 -> B1 -> A1
	 -> B2 -> A1
   -> C2 -> B2 -> A1
         -> B3 -> A1
   -> C3 -> B3 -> A1
         -> B4 -> A1
   -> C4 -> B4 -> A1
         -> B5 -> A1
   -> C5 -> B5 -> A1
         -> B6 -> A1

It becomes obvious that the PropertyChanged event is inefficiently raised 10 times for Property A1 although once would be completely sufficient. Consequently, it is advisable to always take advantage of the smart property notification.

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Caching

The PDFx allows you to cache Property evaluations and thereby avoid unnecessary executions of the very same evaluation business logic while the underlying data stayed the same.
When the INotifyPropertyChanged.PropertyChanged event is fired for a property, its cached value gets invalidated because the PDFx assumes that the underlying data has changed.
If a cached property depends on other properties, the cached value consequently gets invalidated as soon as any of its direct or indirect source properties change.
This feature helps to save precious CPU time when property evaluations become costly.

The following example demonstrates the usage:

class CacheDemonstration : BindableExt
{
	private AnyType _property1;
	public AnyType Property1
	{
		get { return _property1; }
		set { _property1 = value; NotifyPropertyChanged(() => Property1); }
	}

	private AnyType _property2;
	public AnyType Property2
	{
		get { return _property2; }
		set { _property2 = value; NotifyPropertyChanged(() => Property2); }
	}

	public AnyOtherType DependentProperty
	{
		get
		{
			Property(() => DependentProperty)
				.Depends(p => p.On(() => Property1)
				               .AndOn(() => Property2));

			return CachedValue(() => DependentProperty,
			                   () =>
				               {
					               return Property1 + Property2;
				               });
		}
	}
}

To use the caching feature, simply wrap the Property’s evaluation logic in a call to the Method CachedValue. The first parameter points to the current property while the second parameter points to a delegate that evaluates the property’s business logic.

When DependentProperty is evaluated for the first time, it calculates the property’s value and caches it. Whenever the property is evaluated the next time, it returns the cached value without re-evaluating Property1 or Property2.
As soon as Property1 or Property2 change, however, DependentProperty’s cached value is invalidated and upon its next access re-evaluated and cached again.

Simple Example

Let’s consider the following object graph:

Green circles stand for Input Properties while purple circles indicate calculated properties. The arrows show the underlying math operations as well as the property dependencies.

Such a graph can easily be implemented using the PDFx:

class SimpleCachingExample : BindableExt
{
	public int A1
	{
		get
		{
			Property(() => A1)
				.Depends(p => p.On(() => B1));

			return B1;
		}
	}

	public int A2
	{
		get
		{
			Property(() => A2)
				.Depends(p => p.On(() => B1));

			return 3 * B1;
		}
	}

	public int B1
	{
		get
		{
			Property(() => B1)
				.Depends(p => p.On(() => C1)
							   .AndOn(() => C2));

			return CachedValue(() => B1, () =>
				                             {
					                             return C1 + C2;
				                             });
			//Note the usage of CachedValue
		}
	}

	private int _c1;
	public int C1
	{
		get { return _c1; }
		set { _c1 = value; NotifyPropertyChanged(() => C1); }
	}

	private int _c2;
	public int C2
	{
		get { return _c2; }
		set { _c2 = value; NotifyPropertyChanged(() => C2); }
	}
}

A subsequent evaluation of A1 and A2 will result in only one evaluation of B1‘s business logic. Any future request of B1 will return the cached value. As soon as C1 or C2 change, B1‘s cached value gets invalidated and reevaluated when its accessed the next time.

Performance Demonstration

The source code of this example can be found in ViewModel CachingDemonstrationVM which is part of the WPFSample’s source code.

Let’s consider the following object graph:

The indicator next to the calculator icon shows the number of Property Evaluations since any Input Property (E1 through E6) has last changed.

A change of E1 with caching enabled results in the following:

Only D1, C1, B1 and A1 get re-evaluated. This makes perfect sense, since those are the only properties that are directly or indirectly dependent on E1.

Without caching, however, a change of E2 results in the following:

The PDFx notices that D1, C1, B1 and A1 all need to get reevaluated and fires INotifyPropertyChanged.PropertyChanged for all of them. The UI layer consequently accesses all of them and causes a reevaluation.
A reevaluation of for example A1 will now access – amongst others -B1. Consequently, B1 is unnecessarily evaluated again (first time it was evaluated by the UI layer). And the game goes on for all the other properties and has a larger performance impact the more intricate your object graph becomes.

The ViewModel for the example above can be implemented as follows:

class CachingDemonstrationVM : BindableExt
{
	public int A1
	{
		get
		{
			Property(() => A1)
				.Depends(p => p.On(() => B2)
							   .AndOn(() => B1));

			return CachedValue(() => A1, () => B1 + B2);
		}
	}

	public int B1
	{
		get
		{
			Property(() => B1)
				.Depends(p => p.On(() => C1)
							   .AndOn(() => C2));

			return CachedValue(() => B1, () => 2 * C1 - C2);
		}
	}

	public int B2
	{
		get
		{
			Property(() => B2)
				.Depends(p => p.On(() => C2)
							   .AndOn(() => C3));

			return CachedValue(() => B2, () => -C2 + C3);
		}
	}

	public int C1
	{
		get
		{
			Property(() => C1)
				.Depends(p => p.On(() => D1)
							   .AndOn(() => D2));

			return CachedValue(() => C1, () => D1 + D2);
		}
	}

	public int C2
	{
		get
		{
			Property(() => C2)
				.Depends(p => p.On(() => D3)
							   .AndOn(() => D4));

			return CachedValue(() => C2, () => 3 * D3 + 3 * D4);
		}
	}

	public int C3
	{
		get
		{
			Property(() => C3)
				.Depends(p => p.On(() => D5)
							   .AndOn(() => D6));

			return CachedValue(() => C3, () => D5 + D6);
		}
	}

	public int D1
	{
		get
		{
			Property(() => D1)
				.Depends(p => p.On(() => E1));

			return CachedValue(() => D1, () => E1);
		}
	}

	public int D2
	{
		get
		{
			Property(() => D2)
				.Depends(p => p.On(() => E2));

			return CachedValue(() => D2, () => E2);
		}
	}

	public int D3
	{
		get
		{
			Property(() => D3)
				.Depends(p => p.On(() => E3));

			return CachedValue(() => D3, () => E3);
		}
	}

	public int D4
	{
		get
		{
			Property(() => D4)
				.Depends(p => p.On(() => E4));

			return CachedValue(() => D4, () => E4);
		}
	}

	public int D5
	{
		get
		{
			Property(() => D5)
				.Depends(p => p.On(() => E5));

			return CachedValue(() => D5, () => E5);
		}
	}

	public int D6
	{
		get
		{
			Property(() => D6)
				.Depends(p => p.On(() => E6));

			return CachedValue(() => D6, () => E6);
		}
	}

	private int _e1;
	public int E1
	{
		get { return _e1; }
		set
		{
			_e1 = value;
			NotifyPropertyChanged(() => E1);
		}
	}

	private int _e2;
	public int E2
	{
		get { return _e2; }
		set
		{
			_e2 = value;
			NotifyPropertyChanged(() => E2);
		}
	}

	private int _e3;
	public int E3
	{
		get { return _e3; }
		set
		{
			_e3 = value;
			NotifyPropertyChanged(() => E3);
		}
	}

	private int _e4;
	public int E4
	{
		get { return _e4; }
		set
		{
			_e4 = value;
			NotifyPropertyChanged(() => E4);
		}
	}

	private int _e5;
	public int E5
	{
		get { return _e5; }
		set
		{
			_e5 = value;
			NotifyPropertyChanged(() => E5);
		}
	}

	private int _e6;
	public int E6
	{
		get { return _e6; }
		set
		{
			_e6 = value;
			NotifyPropertyChanged(() => E6);
		}
	}
}

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Dynamic Collection Dependencies

Declarative Usage

As described in Collection Dependencies, the PDFx allows you to register dependencies not only on single objects’s properties, but also on ObservableCollections’ children’s properties.

If the Collection is hotswappable, you can instruct the PDFx to listen for replacements of the entire collection instance:

class Demonstration : BindableExt
{
	DependencyFrameworkObservableCollection<ChildClass> _children = new DependencyFrameworkObservableCollection<ChildClass>();
	public DependencyFrameworkObservableCollection<ChildClass> Children
	{
		get { return _children; }
		set
		{
			_children = value;
			NotifyPropertyChanged(() => Children);
		}
	}

	public AnyType CombinationOfAllChildren
	{
		get
		{
		       Property(() => CombinationOfAllChildren)
	                  .Depends(p => p.OnCollectionChildProperty(() => Children, k => k.ChildProperty));
		//Note how a delegate points to the Collections' property, 
                //thereby allowing the collection to be swapped out.

		//Do something with all children and return
		}
	}

	public void ReplaceChildren()
	{
		Children = new DependencyFrameworkObservableCollection<ChildClass>();
	}

	class ChildClass : INotifyPropertyChanged
	{
		private AnyType _childProperty;
		public AnyType ChildProperty
		{
			get { return _childProperty; }
			set
			{
				_childProperty = value;
				OnPropertyChanged("ChildProperty");
			}
		}
	}
}

Overloads of the methods OnCollectionChildProperty and AndOnCollectionChildProperty both allow you to pass in a DependencyFrameworkObservableCollection instance as the first parameter and point to any property of that collection’s children in the Lambda Expression you pass in as the second parameter.
To support hot swapping of the Collection’s instance, you pass a delegate to the OnCollectionChildProperty and AndOnCollectionChildProperty overloads, which points to the Property that contains the Collection.

Example

The source code of this example can be found in ViewModel DynamicCollectionDependencyVM which is part of the WPFSample’s source code.

Let’s assume we are required to implement the following system:

By clicking the “Click here to use Children”-buttons, the user can change the source collection that ultimately feeds into the Destination object:

Green circles stand for Input Properties while purple circles indicate calculated properties. The arrows show the underlying math operations as well as the property dependencies.

Using the PDFx, we can easily implement the depicted system:

class DestinationVM : BindableExt
{
	public DestinationVM()
	{
		Children1 = new DependencyFrameworkObservableCollection<ChildVM>();
		Children2 = new DependencyFrameworkObservableCollection<ChildVM>();
		Children = Children1;

		Children1.Add(new ChildVM(Children1));
		Children1.Add(new ChildVM(Children1));
		Children1.Add(new ChildVM(Children1));

		Children2.Add(new ChildVM(Children2) { B1 = 2 });
		Children2.Add(new ChildVM(Children2) { B1 = 2 });
		Children2.Add(new ChildVM(Children2) { B1 = 2 });
	}

	private DependencyFrameworkObservableCollection<ChildVM> _children = new DependencyFrameworkObservableCollection<ChildVM>();
	public DependencyFrameworkObservableCollection<ChildVM> Children
	{
		get { return _children; }
		set
		{
			_children = value;
			NotifyPropertyChanged(() => Children);
		}
	}
	
	public DependencyFrameworkObservableCollection<ChildVM> Children1 { get; set; }
	public DependencyFrameworkObservableCollection<ChildVM> Children2 { get; set; }

	public DelegateCommand AddToChildren1Command
	{
		get
		{
		return new DelegateCommand(() => Children1.Add(new ChildVM(Children1)));
		}
	}

	public DelegateCommand AddToChildren2Command
	{
		get
		{
		return new DelegateCommand(() => Children2.Add(new ChildVM(Children2)));
		}
	}

	public DelegateCommand UseLeftCommand
	{
		get
		{
			return new DelegateCommand(() => Children = Children1);
		}
	}

	public DelegateCommand UseRightCommand
	{
		get
		{
			return new DelegateCommand(() => Children = Children2);
		}
	}

	public int A1
	{
		get
		{
			Property(() => A1)
				.Depends(p => p.On(() => B1).AndOn(() => B2));

			return B1 + B2;
		}
	}

	public int B1
	{
		get
		{
			Property(() => B1)
		            .Depends(p => p.OnCollectionChildProperty(() => Children, k => k.A1));
			//Note how a delegate points to the Collections' property, 
			//thereby allowing the collection to be swapped out.

			if (Children.Count == 0)
				return 0;

			return Children.Select(k => k.A1).Sum();
		}
	}

	private int _b2;
	public int B2
	{
		get { return _b2; }
		set
		{
			_b2 = value;
			NotifyPropertyChanged(() => B2);
		}
	}

	class ChildVM : BindableExt
	{
		private DependencyFrameworkObservableCollection<ChildVM> _children;

		public ChildVM(DependencyFrameworkObservableCollection<ChildVM> children)
		{
			_children = children;
		}

		private int _b1 = 1;
		public int B1
		{
			get { return _b1; }
			set { _b1 = value; NotifyPropertyChanged(() => B1); }
		}

		public int A1
		{
			get
			{
				Property(() => A1)
					.Depends(p => p.On(() => B1));

				return B1 * 3;
			}
		}

		public DelegateCommand RemoveCommand
		{
			get
			{
				return new DelegateCommand(() => _children.Remove(this));
			}
		}
	}
}

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Collection Dependencies

Declarative Usage

The PDFx allows you to register dependencies not only on single objects’s properties, but also on ObservableCollections’ children’s properties, given that they support the INotifyPropertyChanged interface:

class Demonstration : BindableExt
{
	DependencyFrameworkObservableCollection<ChildClass> _children = new DependencyFrameworkObservableCollection<ChildClass>();
	
	public AnyType CombinationOfAllChildren
	{
		get
		{

		Property(() => CombinationOfAllChildren)
	           .Depends(p => p.OnCollectionChildProperty(_children, k => k.ChildProperty));
			
			//Do something with all children and return
		}
	}

	class ChildClass : INotifyPropertyChanged
	{
		private AnyType _childProperty;
		public AnyType ChildProperty
		{
			get { return _childProperty; }
			set
			{
				_childProperty = value;
				OnPropertyChanged("ChildProperty");
			}
		}
	}
}

Overloads of the methods OnCollectionChildProperty and AndOnCollectionChildProperty both allow you to pass in a DependencyFrameworkObservableCollection instance as the first parameter and point to any property of that collection’s children in the Lambda Expression you pass in as the second parameter.

DependencyFrameworkObservableCollection vs. ObservableCollection / INotifyCollectionChanged

It is recommended to use the PDFx’s API with DependencyFrameworkObservableCollections when dependencies on collection’s children are to be registered, since the DependencyFrameworkObservableCollection offers significant property dependency performance advantages over the ObservableCollection or any other collection that implements INotifyCollectionChanged. It is, however, not required. ObservableCollections and other collections that implement INotifyCollectionChanged satisfy the API as well.

Example

The source code of this example can be found in ViewModel SimpleCollectionDependencyDemonstrationVM which is part of the WPFSample’s source code.

Let’s assume we are required to implement the following system:

Green circles stand for Input Properties while purple circles indicate calculated properties. The arrows show the underlying math operations as well as the property dependencies.

Using the PDFx, we can easily implement the depicted system:

class DestinationVM : BindableExt
{
	public DestinationVM()
	{
		Children.Add(new ChildVM(_children));
		Children.Add(new ChildVM(_children));
		Children.Add(new ChildVM(_children));
	}

	private DependencyFrameworkObservableCollection<ChildVM> _children = new DependencyFrameworkObservableCollection<ChildVM>();
	public DependencyFrameworkObservableCollection<ChildVM> Children
	{
		get { return _children; }
	}

	public DelegateCommand AddCommand
	{
		get
		{
		  return new DelegateCommand(() => Children.Add(new ChildVM(Children)));
		}
	}

	public int A1
	{
		get
		{
			Property(() => A1)
				.Depends(p => p.On(() => B1).AndOn(() => B2));

			return B1 + B2;
		}
	}

	public int B1
	{
		get
		{
			Property(() => B1)
			  .Depends(p => p.OnCollectionChildProperty(Children, k => k.A1));
			//Note the usage of the OnCollectionChildProperty method

			if (Children.Count == 0)
				return 0;

			return Children.Select(k => k.A1).Sum();
		}
	}

	private int _b2 = 0;
	public int B2
	{
		get { return _b2; }
		set
		{
			_b2 = value;
			NotifyPropertyChanged(() => B2);
		}
	}

	class ChildVM : BindableExt
	{
		private DependencyFrameworkObservableCollection<ChildVM> _children;

		public ChildVM(DependencyFrameworkObservableCollection<ChildVM> children)
		{
			_children = children;
		}

		private int _b1 = 1;
		public int B1
		{
			get { return _b1; }
			set { _b1 = value; NotifyPropertyChanged(() => B1); }
		}

		public int A1
		{
			get
			{
				Property(() => A1)
					.Depends(p => p.On(() => B1));

				return B1 * 3;
			}
		}

		public DelegateCommand RemoveCommand
		{
			get
			{
				return new DelegateCommand(() => _children.Remove(this));
			}
		}
	}
}

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Dynamic External Property Dependencies

Declarative Usage

As shown in External Property Dependencies, the declarative PDFx API allows you to register a dependency on a property that resides in any INotifyPropertyChanged-instance different from the owner of the dependent Property.

If the owner of the source property can be swapped out at runtime (or start off as null), you can instruct PDFx to listen for changes of the owner object:

class SourceClass : INotifyPropertyChanged
{
	private AnyType _sourceProperty;
	public AnyType SourceProperty
	{
		get { return _sourceProperty; }
		set
		{
			_sourceProperty = value;
			OnPropertyChanged("SourceProperty");
		}
	}
}

class DestinationClass : BindableExt
{
	private SourceClass _dynamicSource;
	private SourceClass DynSource
	{
		get { return _dynamicSource; }
		set
		{
			_dynamicSource = value;
			NotifyPropertyChanged(() => DynSource);
		}
	}

	public AnyOtherType TargetProperty
	{
		get
		{
			Property(() => TargetProperty)
		            .Depends(p => p.On(() => DynSource, k => k.SourceProperty)); 
                        //Note that the first parameter of the On method is a delegate

			//SourceProperty has changed. Do Something with it and return.
		}
	}

	public void ChangeSource()
	{
		DynSource = new SourceClass();
	}
}

Overloads of the methods On and AndOn both allow you to pass in an INotifyPropertyChanged instance as the first parameter and point to any property of that instance in the Lambda Expression you pass in as the second parameter.
To support hot swapping of the INotifyPropertyChanged instance, you pass in a delegate to the On and AndOn overloads, which points to the Property that contains the Source Property owner.

Example

The source code of this example can be found in ViewModel DynamicExternalDependencyVM which is part of the WPFSample’s source code.

Let’s assume we are required to implement the following graph:

By clicking the “Use External Source”-buttons, the user can change the source “External Source” that ultimately feeds into the Destination object:

Green circles stand for Input Properties while purple circles indicate calculated properties. The arrows show the underlying math operations as well as the property dependencies.

Using the PDFx, we can easily represent the depicted graph in C#:

public class DynamicExternalDependencyVM : BindableExt
{
	public DynamicExternalDependencyVM()
	{
		ExternalSource1 = new ExternalSource();
		ExternalSource2 = new ExternalSource();
		Destination = new DestinationVM() { ExternalSource = ExternalSource1 };
	}

	public DestinationVM Destination { get; set; }
	public ExternalSource ExternalSource1 { get; set; }
	public ExternalSource ExternalSource2 { get; set; }

	private DelegateCommand _useExternalSource1Command;
	public DelegateCommand UseExternalSource1Command
	{
		get
		{
			return _useExternalSource1Command = _useExternalSource1Command ?? new DelegateCommand(() => Destination.ExternalSource = ExternalSource1);
			//Hotswap ExternalSource
		}
	}

	private DelegateCommand _useExternalSource2Command;
	public DelegateCommand UseExternalSource2Command
	{
		get
		{
			return _useExternalSource2Command = _useExternalSource2Command ?? new DelegateCommand(() => Destination.ExternalSource = ExternalSource2);
			//Hotswap ExternalSource
		}
	}

	public class DestinationVM : BindableExt
	{
		public int A1
		{
			get
			{
				Property(() => A1)
					.Depends(p => p.On(() => B1)
						        .AndOn(() => ExternalSource, k => k.A1));
				//Tell the PDFx that ExternalSource might get hotswapped

				return B1 + ExternalSource.A1;
			}
		}

		private ExternalSource _externalSource;
		public ExternalSource ExternalSource
		{
			get { return _externalSource; }
			set
			{
				_externalSource = value;
				NotifyPropertyChanged(() => ExternalSource);
			}
		}

		private int _b1;
		public int B1
		{
			get { return _b1; }
			set
			{
				_b1 = value;
				NotifyPropertyChanged(() => B1);
			}
		}
	}

	public class ExternalSource : BindableExt
	{
		public int A1
		{
			get
			{
				Property(() => A1)
					.Depends(p => p.On(() => B1));

				return 3 * B1;
			}
		}

		private int _b1;
		public int B1
		{
			get { return _b1; }
			set
			{
				_b1 = value;
				NotifyPropertyChanged(() => B1);
			}
		}
	}
}