Databinding

Data validation in WPF, my approach

Whether to use IDataErrorInfo or ValidationRule - that is the question, as I posed in a previous post.

So , you may be wondering what do I do in my WPF projects?
Or you may not

Well, I tend to use both!
I use IDataErrorInfo to provide validation in the business object itself, then derive extra classes from ValidationRule when I want validation across different business objects.

I have tried making the Validation classes always separate from the pure data business classes, but I found it to be counter productive and also counter intuitive.

Data validation in WPF using ValidationRule

As I mentioned in a previous post, you can specify validation by creating a Validation class (or classes).

You do this by deriving a new class from the ValidationRule class and overriding the Validate method.

Why would you do this, instead of implementing IDataErrorInfo?
Well, if you wanted to do validation across a number of objects, then this is the way to go.
It also provides a level of separation from your business objects, leaving them to deal with business data and the validation objects to deal with validation.
A downside is that it is not backwardly compatible with WinForms

How do you tell your xaml to use it? By specifying it in the ValidationRules element of your binding - just like IDataErrorInfo.

Data validation using IDataErrorInfo

As per a previous post, how do you do data validation in WPF using IDataErrorInfo?

Well what does IDataErrorInfo give you? It defines two properties:

public string Error
{
get;
}

public string this[string columnName]
{
get;
}

When you implement these, you provide error validation for your WPF application.

How does that happen?
Well, it doesn’t automatically of course [no surprises there].

When you specify your binding in xaml, you need to specify either the ValidationRules element or the ValidatesOnDataErrors parameter:

<Binding Source=”{StaticResource tradeList}” Path=”Instrument” UpdateSourceTrigger=”PropertyChanged”>

<Binding.ValidationRules>

<DataErrorValidationRule>

</Binding.ValidationRules>

</Binding>

or

<Binding Source=”{StaticResource tradeList}” Path=”Instrument” ValidatesOnDataErrors=”true” />

Re-using data template across controls

How do you use the same data template across different types of control?

Well you can

Normally when you define the data template, you do something like the following:

<DataTemplate DataType=”{x:Type ListViewItem}>
<TextBlock Text=”{Binding Path=ISIN}” />
</DataTemplate>

However, it is a bit of a pain to then copy it for different types, but there is a way:

<DataTemplate DataType=”{x:Type local:Instrument}>
<TextBlock Text=”{Binding Path=ISIN}” />
</DataTemplate>

(where Instrument is a class in your assembly)

This template can now be used with any control type.

Multi value converter in databinding

Here’s a nifty little trick that I recently discovered.

When you need to calculate the result of two properties and display it, you can do it via a Converter class.
You may want to do it, like me, if you couldn’t update the business objects, or didn’t want to.

How do you do it?
Your converter class needs to implement IMultiValueConverter instead of IValueConverter.

E.g.:

Then you specify a multi binding in your xaml, like:

Explicit control of how the source is updated

In a previous post, I described how you can get a binding to update in real time - i.e. as you type.
Sometimes however, you want to control the updating more closely, i.e. in code. For example, you may want to do the update only when a timer has ticked.
There is a little used argument for UpdateSourceTrigger (well in 18 months of using WPF I’ve never seen it used :-)) , namely Explicit that allows you to do that.
Given some xaml like:

<ComboBox Name=”cbUsers” SelectedValuePath=”Name” />
<TextBox Name=”tbUserName” Text=”{Binding ElementName=cbUsers, Path=SelectedValue}” />

When you add UpdateSourceTrigger=Explicit to the TextBox, you can control the updating by telling the binding mechanism to update.
<TextBox Name=”tbUserName” Text=”{Binding ElementName=cbUsers, Path=SelectedValue, UpdateSourceTrigger=Explicit}” />
How do you do that? That’s where the magic lies
You need to get the BindingExpression for the TextBox:

BindingExpression binding = tbUserName.GetBindingExpression(TextBox.TextProperty);

Then update the linked source( the textbox):

binding.UpdateSource();

bingo

Databinding with Linq with automatic updates

How do you databind to an EntitySet retreived from a Linq query, via Linq to Sql or Linq to Entities for example?

Well it is very easy to actually bind to it, you simply connect it up using normal Xaml syntax. But what if you want to have updates automatically relected in the UI? That’s something that ObservableCollection does very well, due to it’s implementation of INotifyCollectionChanged. So why didn’t they implement INotifyCollectionChanged in the EntitySet class? Who knows? It would have saved me a load of grief, for starters.

For a list of your different options, see a previous post of mine.

Here I will show how I have got around the problem:

I have a database table called Profiles, which using the Linq for Sql visual designer gives me a class called ProfilePart. As it is a partial class I can have another cs file with my ProfilePart definition and provide my binding implementation.
How do I it? I call the GetNewBindingList() method on the EntitySet, but I need to cache it as I don’t want to do it every time it is accessed.

An example is shown below:

Combobox - reference not being set

I’ve come across this strange little quoible.
It’s possibly just just the way I’ve been trying to use it, but it still seems odd to me

If you have a ComboBox which you are databinding to using an object, like:

<ComboBox SelectedItem=”{Binding Path=Market}” />
Where Market is a reference to another object

If you fail to initialise the object , Market in this case, the combobox won’t do it!

Obviously, the circumstances in a LOB application are more complex than the simple example above, but it does seem bizarre behaviour.

ListBox - the forgotten control

How did that happen?

I personally think it happened because when we were all looking at WPF to begin with (in CTP days), it was very obvious that there was no Grid.
Then, because of that people noticed that the ListView control had the option to specify a grid version as one of it’s views. That wasn’t so different to Win32 or WinForms, but because of the power of WPF it has been easy to adapt to what we all need.

However, in doing so, we have forgotten about the humble old listbox. As I have re-discovered recently, it is very easy to have multi-column listboxes in WPF.
Therefore when I don’t want to be able to switch views (to icon views etc), but just show Line Of Business style multi-column lists I just might use the ListBox instead. As a warning note, you do lose the ability to generate columns , i.e. you have to do it yourself, but it is really very easy

Change notification

Change notification in WPF is the mechanism by which you proprogate changes to your objects to whomever is listening for those changes.
One typical usage is in a data binding scenario, where the recipient is listening for changes to the objects being bound to in order to update the user interface.

One of the first burning issues in WPF is which way should you go when you need to implement change notification, as you have two choices:

1.Implement the INotifyPropertyChanged in your business objects, and for each property set raise the PropertyChanged event for that property. This notifies the data binding mechanism of WPF that a change has occurred.

2. Create each and every property as a dependency property. This provides the data binding mechanism of WPF with all the details required to keep itself in sync with the data. This means that you don’t need to implement the INotifyPropertyChanged interface and you don’t need to raise the PropertyChanged event either.

How do you choose?

Binding speed - version 2 is slightly faster in most line of business applications
Coding speed - version 2 is slower, due to the need for creating a dependency property - but there are snippets lurking around on the web which will create the basic skeleton for you
Flexibility - version 2 allows you to have bindings both ways in WPF, which can be useful sometimes. By that i mean you can use BindingMode to be OneWayToSource
Backward compatibility - version 1 can be used in winforms as INotifyPropertyChanged is a v2.0 interface

So what do I do?

I tend to use version 1 unless I need that extra 5-10% of speed or I need to be able to reverse the bindings by using BindingMode = OneWayToSource