Given this slightly simplified xaml
<ig:XamGrid CellEnteringEditMode="Items_CellEnteringEditMode" >
<ig:XamGrid.Columns> <ig:TextColumn Key="Number"/> <ig:TemplateColumn Key="Reference"> <ig:TemplateColumn.ItemTemplate> <DataTemplate> <TextBlock Text="{Binding Reference, Mode=OneWay}"/> </DataTemplate> </ig:TemplateColumn.ItemTemplate> <ig:TemplateColumn.EditorTemplate> <DataTemplate> <portalControls:FormComboBox /> </DataTemplate> </ig:TemplateColumn.EditorTemplate> </ig:TemplateColumn> </ig:XamGrid.Columns> </ig:XamGrid>
Hello,
This issue is now resolved in the latest volume release for NetAdvantage, 2010 Vol. 3. Please let me know if you have any further questions or concerns about this matter.
After discussing this issue further the development team it is felt that this should be logged as a new feature request. I'm creating a new case for you in our customer help system and will provide you with further details about the feature request through the case.
This is the expected behavior of the TemplateColumn. A TemplateColumn acts like any of the other columns, with the exception of an UnboundColumn, in that the Key of the column is a property in the data entity that you want to bind to. If that property is a read only property then the column should not support editing.
The real point of a TemplateColumn is to allow you to customize how the data can be presented or edited.
A better approach to implement the behavior you describe would be to create an UnboundColumn that has a Key set to a value that isn't located in the data entity. For example:
<ig:XamGrid.Columns> <ig:TextColumn Key="Number"/> <ig:UnboundColumn Key="MyColumn"> <ig:UnboundColumn.ItemTemplate> <DataTemplate> <TextBlock Text="{Binding RowData.Reference, Mode=OneWay}"/> </DataTemplate> </ig:UnboundColumn.ItemTemplate> <ig:UnboundColumn.EditorTemplate> <DataTemplate> <portalControls:FormComboBox /> </DataTemplate> </ig:UnboundColumn.EditorTemplate> </ig:UnboundColumn> </ig:XamGrid.Columns> </ig:XamGrid>
On consideration, I think this is a bug (or at least a feature which should be documented for TemplateColumn!)
Given a template column
<TemplateColumn Key="Property1"> <TemplateColumn.ItemTemplate> <DataTemplate> <TextBlock Text="{Binding Property2}"/> </DataTemplate> </TemplateColumn.ItemTemplate> <TemplateColumn.EditorTemplate> <DataTemplate> <TextBlock Text="{Binding Property3}"/> </DataTemplate> </TemplateColumn.EditorTemplate></TemplateColumn>
The value of IsEditable is derived from Property1 only, so far as I can tell, even though Property2 is displayed and Property3 is edited (theoretically)
I think Property1 should be ignored in this case because the only thing it's contributing is a non-obvious behaviour which is contrary to all the other context.
The column key (reference) didn't have a setter, so column.IsEditable was false and attempts to edit were ignored.
I'd suggest perhaps that template columns which have a defined edittemplate which is bound to something other than the column key should be treated as editable if the editor binding has a setter.
In any case, it's a change & caught me out upgrading to 2010.2 Maybe this will help someone else :)