Our new project at work has chosen WPF for our UI Framework. There is a nervous feeling around the office that WPF might not be the proper choice, due to the nature of WPF or the quality of the development staff and the staff to follow. After spending a few days in WPF and developing a really rough prototype, I have to admit I am pretty sure we will put both concerns to rest. WPF has so many features that make it suitable to Line of Business applications, whatever that term truly means. While I haven’t mastered WPF in the past few days, I have a fairly good understanding of those features and usage potential.
The hardest myth to overcome is that WPF is only for the shiny, glossy, media rich applications. While it is excellent at delivering those user experiences, it is filled with numerous techniques that would provide use to any desktop application (except maybe command line applications).
I’m not going to try and do a job of completely enumerating why I’m excited about using WPF in a Line of Business application, but a brief list might help to summarize them.
Layout Managers
My WinForms experience includes mostly .Net 1.1 and VB6 over the past 10 years or so, but I do have a sprinkle of experience doing UI in Java Swing. The layout managers Java had looked like they would be a huge advantage over the absolute position of .Net and VB6. WPF introduces similar functionality with content containers.
There are several devices for laying out controls on the design surface. Before, when using the .Net 1.1 devices such as Dock it was very awkward to get the layout fluid. Controls required manual resizes and would often overlay other controls unexpectedly.
With new containers like StackPanel, Grid, DockPanel, etc. and the ability to nest them as needed, complex layouts become more manageable.
Even the controls themselves have the ability to be more flexible with their layout. Making three controls proportionally resize in WinForms required handling events, doing math to determine the new sizes based on the proportions and setting the sizes of each control. With WPF, you do the following:
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="1*" />
<RowDefinition Height="1*" />
<RowDefinition Height="1*" />
</Grid.RowDefinitions>
<TextBox Grid.Row="0" />
<TextBox Grid.Row="1" />
<TextBox Grid.Row="2" />
</Grid>
Control Content Containers
In WPF near everything is a container. You want a checkbox inside a button? No problem.
<Button>
<CheckBox>Cool<Checkbox/>
</Button>
Some controls, like TextBox doesn’t accept custom content. While this doesn’t appear useful at first, but the ability to override the content generated by list boxes provides am endless array of options. I imagine this will work like a repeater in ASP.Net.
Data Binding
By far the most impressive feature of WPF, at least to me, is the ability to bind, not only data elements, but also control properties and wire these bindings to other properties. There is a new rich model for binding almost anything to almost anything else. I know this seems a little vague at the moment.
The heart of the robust data binding is the dependency property. It allows for change notification as well as a few other nice features. Since the controls of WPF have their properties implemented by dependency properties, the binding is notified when they change and can bind the appropriate values.
Data binding could be used, for example to bind the font size of a grid cell to the value which it holds. We could a custom converter to convert the value of the cell to a font size or even to a color. Likewise, you could bind the text of a tooltip to an error message produced via a validator that is run when a text box value has its value changed.
Baby Steps
There are too many features to enumerate. I am about 250 pages into Programming WPF. 
I usually hate buying language books and prefer something with a little more longevity, but so far it has been a really fast read. I can’t say it is going to be the last WPF book anyone will every need, but coming from zero WPF knowledge, it has shed some light on the features of WPF that I see valuable. There are many more things mentioned in the book that I forgot to mention, haven read yet, poorly or entirely incorrectly phrased. :S This is by no means an expert synopsis of WPF.
While I’ve gotten my hands slightly dirty in WPF over the past week, I haven’t even begun to leverage its full power. I plan on keeping everyone abreast of my progress, short comings, troubles and successes…hopefully more of the later.
I am considering keeping a sample project running to show where I’m at in my WPF journey, but haven’t decided if it will be of value or interest to anyone. It would most likely be a simplified obfuscated version of my current project and a testbed for running spikes.
In most factories, especially those that pride themselves on their safety records, you’ll find a sign that says something like “600 days since our last lost time incident”. We should have the same for our automated build qualities, although I doubt they will ever reach 600 days of consecutive green builds. It would hopefully generate a sense of pride in the build. Imagine if you joined a team that had 60 days of green builds and that number was publicized for the entire organization to see. Wouldn’t you take extra care to make sure you don’t do something that flips it over to red, even for one build?
