You can’t do that in WPF?

One of the things that virtually everyone talks about whenever they start learning WPF is how amazing the experience is – there are virtually no limits to the amazing stuff you can do. Or put in a different way; The hard becomes easy, the impossible becomes possible.

However, one thing I have not found a way to do (and which is apparently not currently possible, according to the answer I got on StackOverflow.com), is how to handle databinding in the case where you want to bind to an interface, and not the actual object.

In my case, I have a list of business objects that represent the ItemsSource for a ListBox. Each of these objects contains two other objects. These objects can be one of several different types, the only thing they have in common is that they implement a specific interface. The problem here is that the ItemTemplate I use cannot refer to the Interface properties – the binding engine will only see the object as the type it really is, not the interface.

While this isn’t a HUGE thing, it is a weakness that would be very nice to be able to work around in an upcoming update of WPF.

WPF ComboBox binding to LINQ to SQL

This is mostly for my own use – I am senile enough to run into this problem again in the future.

Like all controls in WPF, the ComboBox is full of configurability and extensibility. This can get quite hairy quite quickly – and if you set the wrong parameters when you databind to a LINQ to SQL data source, really funky stuff can happen.

So here is something that worked for me:

<ComboBox Grid.Column="1" Grid.Row="1" VerticalAlignment="Center" IsEditable="False"   

          Margin="10,2" 

          ItemsSource="{Binding Path=Produkt.Modeller}"  

          DisplayMemberPath="Modell"  

          SelectedValuePath="Modell"  

          SelectedItem="{Binding Path=ProduktModell}"  

          />

ItemsSource is relatively easy – just point at the collection of options.

DisplayMemberPath is also relatively easy – it just tells WPF what to display in the ComboBox.

But SelectedValuePath and SelectedItem took some experimentation to get right – the above works for me, but with some variation came some pretty strange bugs. Models being renamed and stuff.

So now I know.

Book impression – Programming WPF

So, I was a complete newbie when it came to WPF, but because of Sloth and other applications, I was curious about what this was, as I must admit that UI programming in Windows has been a serious annoyance. Perhaps that’s the way it has to be when you come from a background of Amiga programming, with som web stuff thrown in for good measure.

I think I can safely say that I now have a pretty good grasp of how I can use WPF for creating better experiences for the users of my software. There are a lot of things I can do now that I couldn’t before, and the whole layout model makes a lot more sense. Declarative programming is definately the way to go when it comes to GUI programming, IMHO.

So, what about the book? Well, like many programming books, it’s hard to just read it without a keyboard and a compiler nearby. You want to try out the stuff as you go along, and the book rightly encourages you to do so. The logical progression of things felt a little off at times, and in places it felt more like a reference book than an end-to-end learning experience. Particularly when it came to look at data binding, I must admit I struggled a bit; Their explanations were very good, but I left those chapters feeling like the authors should have given more attention to databinding towards CLR objects; After all, WPF representing the presentation layer, I would expect most non-trivial applications to have some model data to show; It won’t all be created as part of the XAML.

Other than small gripes like this, I feel like I have a pretty good idea of the things you can do with WPF. Of course it doesn’t touch on features of .Net 3.5 Sp1 such as the possibilities of creating grid views (the book came out long before Sp1), so while this is not the fault of the authors, if you want to learn about the new features of Sp1, you have to look elsewhere.

So, is this brick worth reading through? If you’re stuck with WinForms and want a better way to do things, go for it! There is a lot you can do with WPF that would be very hard with the old ways, and I for one believe that WPF represents the future of UI programming. I will surely use it for my coming client applications, and I will keep this book nearby as a handy reference.

My copy of the book is “Programming WPF, Second Edition”. It is published by O’Reilly, and authored by Chris Sells and Ian Griffiths.

Automatically implemented properties and WPF

This blog hasn’t lived much recently – I’ll try to post a little more, but no promises (since noone reads it anyway).

I’ve been looking into Windows Presentation Foundation lately, and it is very fascinating; It opens up a lot of doors for new UI possibilities, but also quite a few new challenges. If you want to display your object model in the “WPF way”, one of the things you have to do is implement INotifyPropertyChanged. This allows WPF to pick up on object changes and update the user interface accordingly.

One of the very helpful new features in C# 3 (i.e. the language, which confusingly was released with .Net 3.5) is automatically implemented properties. Basically these guys allow you to implement trivial properties on objects without a lot of code, backing fields etc. A one-line property makes code more readable, and you have less possibility of failure in a no-code property than one that contains some code.

These two things put together, however, are currently not compatible by default. If you have an automatically implemented property, it will not notify WPF of changes to its’ value. There are of course ways of doing this using reflection and attributes and such, but wouldn’t it be really cool if the C# compiler knew of INotifyPropertyChanged and actually triggered the PropertyChanged event for you automatically on these autoprops?

I certainly think so, but I can see why some people would disagree.

No matter what, I think it would be really useful.