Get Column in CellTemplate

[Charles]

I've tried everything I can think of to get this binding to work...

My situation is this:

I have a grid which has Columns generated in the code behind.  These are dynamic depending on something the user has chosen.  Each column has its Tag property set to a related object.

The rows are a collection bound to ItemsSource.  There is no corresponding property on the underlying item that matches a column, but there is a method that will return an object (e.g. item.GetItemForCell(string columnTag).

What I need is for a binding for the Cell to be able to return the correct object, and allow editing of the object.  For this, I need to get the row and the column it's in (for row.Item.GetItemForCell(column.Tag))

To do this, I've tried creating a converter that is expecting a GridViewCell (alternatively it could just take the column as a parameter).  To use this, I've set up a binding in the code behind as follows:

var binding = new Binding(".");
binding.Mode = BindingMode.TwoWay;
binding.RelativeSource = new RelativeSource(RelativeSourceMode.FindAncestor, typeof(GridViewCell), 1);
binding.Converter = new FactProxyConverter();

This is then applied to the DataMemberBinding of the GridViewDataColumn.

This... sort of works.  The converter is called with the GridViewCell, and each cell shows a "ToString()" representation of the object.

So I thought I'd put a cell template on.  I set CellTemplate in the code behind to FindResource("template").  But the binding doesn't bind to the converted object, it binds to the row's Item property.  Argh!

I tried creating a DataTemplate resource with the DataType of the object I want to template, but it's ignored.

I tried moving the binding to the DataTemplate, but even using the same binding as above the row's Item property is passed to the converter rather than the GridViewCell.

Any ideas?!  It doesn't seem like that big an ask, but I feel like I've been banging my head against a wall all day.

[Ivan Ivanov]

Hi Charles,

The CellTemplate's DataContext won't be the converted value from DataMemberBinding, but the bound item instead. Moreover, it is not quite recommended to bind the DataMemberBinding to a visual element. As a rule of thumb, data-driven approach should be used when it is possible. Would it be possible for you to send us a simple runnable project that illustrates your ideas, so that we could investigate them, discuss them with you and find the best solution for your case?

All the best,
Ivan Ivanov
the Telerik team

[Charles]

Hi Ivan

Yes, probably a better idea - the wall of text isn't really as easy to understand as a demo!

I've submitted a support ticket (559369) with an attached project (as I can't seem to attach zip files here..)  You can see each cell is populated with the "ToString()" output of the object returned by the Converter called by the binding on DataMemberBinding.

What I am after is a way to template that cell so that it can show *and edit* a specific properties on the underlying object.

Thanks!

Charlie

[Ivan Ivanov]

Hello Charles,

I have run and debugged the project that you have sent to us via the mentioned support ticket, so I am up to share my observations here. I have noticed that you have defined a TwoWay binding to a "." Path. Would you please shed some more light on this? Is it meant to work like an OneWa\yToSource binding, as Source>Target won't work correctly if it is defined like this? I have dared to apply some changes, but I might have guessed wrong. As for the DataTemplates, you can reuse the binding and build them using FrameworkElementFactory. Would you please refer to the attached version and comment on my changes? Please, pay attention that the I have left the ConvertBack implementation to you as I am not quite sure what is your eventual goal, so that the editing "copies" the value on ConvertBack.

All the best,
Ivan Ivanov
the Telerik team

[Charles]

Hi Ivan

Thanks for getting back to me - the revised project was pretty helpful!  I think in creating it, I managed to get rid of some of the subtleties that might have made it easier to understand what I was getting at.  In reply to your points:

- The binding to "." (which is the same as "{Binding}" in xaml) was required as I needed the whole "RowItem" to be passed to the converter, as this (in the original solution I was struggling with..) has the method on it (essentially a sort of indexer) that gets the instance of the item I need to bind to.  I've changed "RowItem" in this to more closely reflect this.

- The "TwoWay" binding is probably wrong - I changed it to one way.  The underlying converted item isn't going to change, as I want to bind to a property on that object.  I can leave the "ConvertBack" as it is.  Essentially, I'm just using the Converter as a way of passing parameters to a Binding.

By declaring the DataTemplate in code, I can use the "ClonedBinding", which I've changed to bind to ".", as the DataTemplate's DataContext.  I can then create a new binding for the TextBox/TextBlock.  This seems to work.  I've attached the updated version to the ticket.

Ideally, I'd like to be able to declare the DataTemplate in XAML... though I can't think of a way of setting the DataContext correctly if doing it this way.  If you have any ideas, it would be appreciated - but I'm guessing I'm stuck with it!

I've also removed the DataMemberBinding, as I'm not sure it's actually used for anything when I've bound to ".".  Is there any disadvantage to this?  I guess I lose sorting, grouping etc by binding to an "object", but I can't work out how to get the binding I need here... setting DataContext doesn't have the same effect as the templates.

Thanks for your help.

Charlie

[Ivan Ivanov]

Hi,

I have come to a solution that utilizes XAML defined DataTemplates. In order to enable filtering and sorting when binding like this, you have to implement the IComparable interface on your data item class. I have modified the project, implementing these changes. The updated version is attached for your reference.

Greetings,
Ivan Ivanov
the Telerik team

[Charles]

Thanks - that's interesting.  Think I've got a few things to work with now, problem more-or-less solved!

[Ivan Ivanov]

Hello,

I am glad to know that. Feel free to contact us again if any further inquiries occur.

Kind regards,
Ivan Ivanov
the Telerik team