C

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:

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.

Popup box

One thing that I have noticed, out there in the real world, is that people new to WPF haven’t noticed the (slightly) unsung hero Popup.
I have actually seen people spending man weeks recreating a floating window as per the popup control in WPF.

So what is it? Well it is the ancestor class for menus, tooltips and the combobox - and provides the necessary floating behaviour.

An example of using it is:

<StackPanel>
<ListBox Name=”xxx” />
<Popup PopupAnimation=”Fade” Placement=”Mouse” x:Name=”pop”>
<TextBlock Text=”ggggg” />
</Popup>
</StackPanel>

This example will show a floating window at the mouse cursor, when the mouse is in the stackpanel. Easy as pie isn’t it?

Template bindings

If you want to, for example, to override a control template for a control in WPF, it is quite easy and very powerful.

One great thing is that you can specify a templatebinding instead of a (slightly) convoluted syntax to specify the property you are binding to. An example:

<TextBox Text=“{Binding RelativeSource={RelativeSource TemplatedParent}, Path=ValueString}“
This points the text property, in your template, to gets it’s value from the property called ValueString in the xaml that specifies the textbox instance, however it can be changed to:
<TextBox Text=“{TemplateBinding Path=ValueString}“

Much simpler isn’t it.
It also has the benefit of being more efficient than the first version as well, it justs gets better doesn’t it.

However, there is a downside, as I found to my cost yesterday
It is one-way only, so if you keep wondering why changes are not being propagated back, wonder no more.
If you want two-way, then you need the first version unfortunately

ListView - is it really too slow?

I have seen a number of blog entries along the lines of ‘ListView is too slow’, or ‘WPF is too slow’, or the worst one of all ‘ListView has performance issues’.
Obviously none of them mention any details, nor elaborate on what issues there might be - sounds a bit like an old project manager of mine :-)

So, what is the reality? That is difficult to know, as there a number of things that can adversely affect the performance of a ListView - but are by no means certain to do so!

Some of the things that may affect performance are:

• Embedding the ListView inside a StackPanel
• Embedding the ListView inside a ScrollViewer
• Not setting ScrollViewer.CanContentScroll to true
• Having too many columns
• Having UI Virtualization turned off (VirtualizingStackPanel.IsVirtualizing)

 There may be some more!

To answer the question, is it too slow? As long as you follow the above, then no
 

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

Localisation

Let me firstly describe the localisation support in WPF - absolute pants
For those people who might read this who don’t understand the local London, UK colloquial term pants - it simply means very bad.

Essentially you get the same localisation engine as v2.0 Windows Forms without the design time support. Therefore you can generate csv files for each different culture, edit them, maintain them and recompile to be able to switch languages. It’s a bit horrible though.
Alternatively you can maintain resources for each culture in resource files and bind to them.
There is a good article on code project which describes the three methods localisation in WPF:
http://www.codeproject.com/WPF/WPFUsingLocbaml.asp

VS2008 doesn’t seem to address this either, so I would like the boys and girls in Redmond (et al) to attack this with the same verve as they did the ORM problem. They came up with such a great solution for that, that I don’t think it has sunk in yet just how great it will prove to be.