DataContext of GridViewHeaderRow

[Alexander]

There is problem with the DataContext of children inside the GridView:
For some reason, the DataContext of the GridViewHeaderRow gets overwritten by a local value (of type System.Object). Therefore, the property is not inherited and it is not possible to bind to members of the GridView DataContext any more!

The value is overwritten in DataCellsPresenter.cs (the corresponding line marked bold), although I don't see any reason to do this:

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    this.ItemsHost = this.GetTemplateChild("PART_ItemsHost") as Panel;
    GridViewRow gridViewRow = this.RadRowItem as GridViewRow;

    if (this.RadRowItem != null &&
        this.RadRowItem.GridViewDataControl == null)
    {
        this.RadRowItem.GridViewDataControl =
            this.RadRowItem.ParentOfType<GridViewDataControl>();
    }

    if (gridViewRow != null)
    {
        this.Item = gridViewRow.Item;
        gridViewRow.EnsureDataCellsPresenterSize();
    }
    else if (this.RadRowItem is GridViewHeaderRow)
    {
        this.Item = new object();
    }
    else if (this.RadRowItem is GridViewFooterRow)
    {
        this.Item = this.RadRowItem.GridViewDataControl.AggregateResults;

        this.TrackAggregatesChanges(this.RadRowItem.GridViewDataControl.AggregateResults);
    }
    else if (this.RadRowItem is GridViewGroupFooterRow)
    {
        this.Item = this.RadRowItem.Item;
    }

    // At the time that a Row is prepared we can't Sync because the CellsPresenter isn't created yet.
    // Doing it here ensures that the CellsPresenter is in the visual tree.
    this.SyncProperties();

    this.SetFrozenColumnSplitterPosition();
}

[Ivan Ivanov]

Hello,

Actually this was a design decision that was taken with one of the first versions of RadGridView. In our view, back then, it was not natural that one of the rows inherit its DataContext from the parent control. Although it is difficult to judge which is the correct behavior, making any changes to the current one may turn to be a major breaking change for a lot of our clients.

Regards,
Ivan Ivanov
Telerik

 

 

[Alexander]

Thanks for your confirmation. I have to admit that I can't think of any case where having a plain System.Object as DataContext could be useful (Binding to it is not possible, as there are are no properties) - so in any case you will have to use a different source when binding...

[Ivan Ivanov]

Hi,

Well, this serves more like a limitation for an arguably undesired behavior - inheriting DataContext from parent. The current implementation suggests that custom headers that contain framework elements should get bound with an explicitly specified binding source. It is easy to refer to the ViewModel as a source for such bindings if it is exposed in XAML as a resource, but if this is not the case, things can easily turn to be more complex. 

Regards,
Ivan Ivanov
Telerik