I’ve spent the better part of the day trying to figure out how to style the column headers of my WPF Toolkit datagrid through Microsoft Blend. Blend is a great tool and I couldn’t imagine trying to do a WPF application without it; however it is still immature and this could be why I found it so difficult to figure out. It could just be that I’m new to Blend, WPF, and XAML and still have a lot to learn.

I’ll spare you the agony I suffered this morning and jump right into the solution.

We have a pretty basic style for the datagrid at the moment. You’ll have to forgive the visual obfuscation.

Changing the the column header style looked pretty obvious in Blend. The menu walks me through the steps to create a resource for the header style.

Give the style resource a name. In this case I am going to show a pivoted set of data with a set of frozen columns on the left and columns that accept entering data on the right. I give it the name I want and choose its destination.

When the steps are complete, I have a style in the resources dictionary for my window, but something is missing.

I’m not sure if I’m missing a step, but the target type of the resource is the generic IFrameInputElement type. It doesn’t provide any properties to set in the designer.

<Style x:Key="EnterableColumnHeaderStyle"/>

The examples I’ve been seeing have a TargetType property to allow for the attached properties to work properly. I got ahead and add my TargetType property.

As you can see, I’m still learning WPF and XAML.  ReSharper steps in and offers to help out a bit. I am glad to let it. It adds the proper namespace to the resource:

<Style x:Key="EnterableColumnHeaderStyle" TargetType="primitives:DataGridColumnHeader">

It also creates the namespace directive:

I don’t really like the namespace alias, so we’ll change it with the help of ReSharper.

Blend now knows our target type and gives us all the properties we could want to style.

We can do whatever we want with the column header now.

And, just as we’d expect, we get our new style.

We can also apply a style to a particular column.

<wpfToolkit:DataGridTextColumn x:Name="FirstColumn"   Header="Something"  HeaderStyle="{StaticResource FrozenColumnHeaderStyle }" >

In an attempt to provide a total summary column in a WPF data grid, I attempted to bind a read only column of a DataTable to a DataGridTextColumn of the WPFToolkit data grid.

Initially, I tried to do the way I’ve been doing every other column.

<wpfToolkit:DataGridTextColumn
     Header="Total"
     DataFieldBinding="{Binding Total}"  />

Unfortunately that gives us the following error:

A TwoWay or OneWayToSource binding cannot work on the read-only property ‘Total’ of type ‘System.Data.DataRowView’.

OK, that makes sense, we should just adjust the mode of the binding and try again.

<wpfToolkit:DataGridTextColumn
     Header="Total"
     DataFieldBinding="{Binding Total,Mode=OneWay}"  />

….but we get the same error. After a few quick Google searches, I found someone else that already pointed out the issue and a possible workaround.

ReadOnly columns is missing from the CTP, but that is not a huge problem, you can easily accomplish ReadOnly behavior by using DataGridTemplateColumns and replacing the templates with read-only controls ( like TextBlocks).

A quick change of the column to a DataGridTemplateColumn and it looks like we are off to the races.

<wpfToolkit:DataGridTemplateColumn Header="Brand">
    <wpfToolkit:DataGridTemplateColumn.CellTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Path=Brand,Mode=OneWay}" />
        </DataTemplate>
    </wpfToolkit:DataGridTemplateColumn.CellTemplate>
</wpfToolkit:DataGridTemplateColumn>

NOTE: After another bit of searching on the web, the WPF Toolkit – October 2008 was released last week. This negates the need for the workaround for read only columns.

<wpfToolkit:DataGridTextColumn
     Header="Total"
     Binding="{Binding Total}"
     IsReadOnly="True" />

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.