|
I was recently doing some work on a WPF application doing some pretty standard stuff. I've got a model object graph and I'm binding a piece of my user interface to a specific piece of that graph - very typical, very normal stuff. Here's the rub: I found myself asking WTF?!?! multiple times.
Basically, I wanted to accomplish a simple string binding. I wanted to have a TextBlock object that contains the following text : "You are chatting with (databound name)". Given how powerful and flexible WPF is, you might think that you might be able to do this:
<TextBlock Text="{Binding Path=RemoteName, FormatString=You are chatting with {0}}"/>Unfortunately, you can't even come close to doing that. Here's where I got pissed off: both Flex (Adobe) and Cocoa (Apple) allow you to directly supply inline format strings. Flex let's you do it through the binding syntax and you can supply format strings directly in Apple's Interface Builder.
Here's where it got nasty. In order to bind this elegantly (and not cheat/hack by creating two textblocks, one bound, one not bound), I had to create a class that implements IValueConverter and then specify that class within the binding syntax so that an instance of that class would be used by WPF to "convert" my value. In other words, I could do this:
<TextBlock Text="{Binding Path=RemoteName, Converter={StaticResource RemoteNameConverter}}"/>Where RemoteNameConverter is a WPF resource that points to an instance of my RemoteNameStringToStringConverter class (yes, that's what it looks like if you follow the recommended naming conventions).
Maybe I'm having a bad day because of the DST timeshift, or maybe I've been spoiled by Interface Builder letting me do what I want, where I want to do it, or maybe I'm just cranky.. but the fact that WPF won't let me dynamically format databound values directly within the data binding syntax/GUI editor is assinine. Oh well, there's always hope that this will get better in v3.5. Guess I'll have to wait for PDC 2007 to find out.
Points for today's exercise:
True. WPF does not have this functionality built in (yet). However, you
should read these two posts by Petzold concerning a solution:
http://www.charlespetzold.com/blog/2006/03/200923.html
http://www.charlespetzold.com/blog/2006/03/310910.html
That "solution" is exactly what I mentioned in my blog post. The notion
that I would have to create a new class for every type of string I want
formatted that has a Convert method is just silly. This kind of thing
should be baked into the product, regardless of whether it's a "v1.0" or
not.
Kevin, you'll have to look at the code a little closer. He's not creating
a class for every scenario. He has created a class that encapsulates all
of the functionality of string.Format. The first class is for the basic
scenario that includes only one parameter, while the second class allows
for n parameters. I don't disagree with you fundamentally, this sort of
feature should not have been left out of the framework itself, but its nice
to know that it's still easy to accomplish.
Yes, you're right. He uses a fairly flexible FormattedStringConverter class
in order to accomplish this, so it's not horrible. I'm simply saying that
the fact that one must go and create this class and then re-use it across
every subsequent WPF project reminds me of the days when all developers
carried a library of "tools" they had developed to compensate for the lack
of tools provided by their language of choice (anyone remember toting their
C string libraries around like garlic in a vampire mausoleum?).
Inline string formatting is now supported in recently released .NET 3.5 SP1
Beta.
Check
http://dotnet.org.za/rudi/archive/2008/05/16/using-binding-stringformat.asp
x
for a usage example.