Datagrid - adding databinding to a built in style

Here is the problem...

I would like the foreground color of certain rows of data be different than other rows based on some criteria. This does not affect the data displayed in the individual cells, only the appearance of the cell.

I looked at various options - firstly overriding the DisplayTemplate for each column. I would have liked to use the same DisplayTemplate for each, but, because I need to use different StringFormats for the different fields. When I override the DisplayTemplate, it just ignored my DisplayMemberBinding. So I basically had to do a separate template for each an every column. This is highly redundant.

After some investigation I found that replacing the BuiltInDisplayTemplate would be a lot easier. I would only have to define one template which would work for every column, and the DisplayMemberBinding would control what was actually display. That would be perfect, except for one thing, my binding which determines the foreground color doesn't actually work.

The main issue is that I need to bind to a property of the current item in the list. What I get as a DataContext is the datatype of the value in the cell. So an Int32 if it is a integer value, or a String if it is a string... whatever. This behaves much differently that what you get if you override the DisplayTemplate for a column - where you get the data item for the whole row. I guess I get why, but that still doesn't help me.

Any suggestions?
Thanks

<TextBlock  Text="{Binding}">
        <TextBlock.Foreground>
          <MultiBinding Converter="{StaticResource IsSpecialItemToColourConverter}">
            <Binding Path="Index" />
            <Binding Path="DataContext.NumberOfSpecialItems">
              <Binding.RelativeSource>
                  <RelativeSource AncestorType="{x:Type Window}"/>
              </Binding.RelativeSource>
            </Binding>
            <Binding Path="DataContext.TotalNumberOfItems">
              <Binding.RelativeSource>
                  <RelativeSource AncestorType="{x:Type Window}"/>
              </Binding.RelativeSource>
            </Binding>
          </MultiBinding>
        </TextBlock.Foreground>
      </TextBlock>

Hi Eliz,

I would recommend bringing this logic up to the row level. Create a Style that targets DataGridRow and use either a binding-converter or a trigger to set the Foreground. Anything within the visual tree of the row that doesn't have a hard-coded Foreground will pick up this value. Here is an example of using a trigger. The Content property gives you the data object of the row that came out of the items source you set on the DataGrid.

<Style x:Key="{x:Type ms:DataGridRow}" TargetType="{x:Type ms:DataGridRow}">
  <Style.Triggers>
    <DataTrigger Binding="{Binding Content.FirstName, RelativeSource={RelativeSource Self}}" Value="Iona">
      <Setter Property="Foreground" Value="HotPink" />
    </DataTrigger>
  </Style.Triggers>
</Style>

This option could work for you if you have a handful of different foreground colors to work with. If however you're going to have many colors, such as being generated from a function applied to one of the row values, then you'll want to use a Setter in the Style to set the Foreground property and have the Value use a binding with a converter to generate the color.

Hopefully this solution works out better than recreating all the display templates. Let me know how it goes.

-Jason Fauchelle

I knew I could count on you for a better solution. I went for the Setter with a binding because I already had a converter handy. That works perfectly.

On a side note, is it possible that the AllowEditing and IsVisible properties of the DataGridColumn are not dynamic? I added a binding to prevent the user from editing a column under certain conditions and it doesn't work. As far as I can tell my binding is correct. It is simple enough, it is just bound to a checkbox on the form.

Hi Eliz,

Those properties are dynamic, but you've run into a limitation which I've now fixed. DataGridColumn was more of a model object, meaning it wasn't becoming part of the visual tree, so most bindings wouldn't work - they didn't have data contexts, and there was no parent element, so no way to route through the visual tree to find other elements. I've changed DataGridColumn to be a FrameworkContentElement which allows data binding on the columns to work just like any other element.

This update will be available in the next nightly build. Let me know if you have further questions about this.

-Jason Fauchelle

You are fantastic. I will check it out ASAP

Thanks Eliz

It will be available about 11 hours from now, let me know how it goes.

-Jason Fauchelle

So far no luck. I've tried various bindings - elementType, or AncestorType for example. With the elementType binding I get the following binding error:

Cannot find source for binding with reference 'ElementName=m_levelsPanel'.

I am using the Mar 7 installer.

Hi Eliz,

I was able to get it working with simple bindings such as:

IsVisible="{Binding IsChecked, ElementName=isVisible}"

and:

AllowEditing="{Binding AllowEditing, Mode=TwoWay}"

If it's still not working, please send me a simple repro project and I'll look into it for you.

-Jason Fauchelle

At long last I finally grabbed some time to put together a test app!!

The attached solution has a datagrid using all my special editors and such, and contains the binding error I described.

Although the exercise did reveal something interesting. We are using an Alloy theme, and for some reason when I apply the theme, I get the binding error, without the theme I have no problem. I haven't had a chance to look into why, but probably my style is out of date or something. The theme can be disabled from the app.xaml file.

So, if you happen to spot the problem before I have a chance to find it that would be very much appreciated. However... I do have another reason why this test project might be useful, because I found another problem.

I have two enumeration properties that I have custom editors for because I want to use special display strings, not the default enum values. Now, what is interesting is that because I have a mix of readonly properties and editable properties I thought it would be nice to show the editors by default rather than having the user click to access them. So I used the IsAlwaysInEditMode="True" option on the columns that are editable.

However, what this causes is that the comboboxes don't work properly - I can select a new value, but the selection is never sent to my property. If I don't use IsAlwaysInEditMode the custom editor works fine. In the test application there are two similar columns one set up with IsAlwaysInEditMode set to true, the other not. Just to be complicated these are the same columns that are supposed to be hidden by default - where the binding doesn't work. In the sample, there is a handy toggle button at the top that is supposed to show/hide these properties.

Thanks again for you help!!

Hi Eliz,

Thanks for sending through the repro project.

I've narrowed down the binding issue to the Alloy.DataGrid theme file not having the DataGridFilterRow within the ScrollViewer style. I have no idea why this is affecting the binding on the DataGridColumn objects - this is really unusual. At least you'll be able to fix the issue by updating the Alloy.DataGrid styles though.

The IsAlwaysInEditMode feature was quite experimental, and as you've found a bit buggy. I will not be able to fix this issue at present unfortunately. Would you be able to try setting the CellEditModeBehavior property on the DataGrid to OnClick instead? This is not quite the same, but will mean clicking on any writeable cell will put it in edit mode instantly, making the ComboBox available in one less click, which you may find better than the default behavior.

Hope that helps.

-Jason Fauchelle

I updated the themes, and that resolves my binding problem, so thanks for that.

I definitely prefer the OnClick for CellEditModeBehavior - especially for comboboxes - 2 clicks rather than 3. I think I will use OnClick as my default. It doesn't accomplish what I was trying to do - which was to show visually which fields are editable - because I have a mix of editable and not-editable fields.

It's not the end of the world, but it would have been nice. Is the bug now officially logged in your system?

Hi Eliz,

Yes, this bug is certainly logged at our end. Sorry we couldn't provide the behavior you were going for.

-Jason Fauchelle