I am using MVVM. My VM has two properties (1) [Data] which returns ObservableCollection<Account> and (2) [AccountAttributes] which returns ObservableCollection<AccountAttribute>.
I View's code behind DataContext set to above class. [Data] is bound to xamDataGrid and it works fine. I want to bind an property in [AccountAttributes] to XamComboEditor which is linked to a column in xamDataGrid. What is the exact syntax in XAML? If I change [AccountAttributes] to List<string> it works fine but want it to be an ObservableCollection.
Thanks.
Hello Jay,
Thank you for the implementation description you have provided.
Presuming that you would like to bind an ObservableCollection of class instances to the XamComboEditor when using MVVM, you can specify the display and value values that will be used for the binding. (DisplayMemberPath and ValuePath properties of the editor)
C#:
public class AccountAttribute{ public int AccountValue { get; set; }} public ObservableCollection<AccountAttribute> AccountAttributes { get; set; }
public ObservableCollection<AccountAttribute> AccountAttributes { get; set; }
XAML:
<Style TargetType="igE:XamComboEditor"> <Setter Property="ItemsSource" Value="{Binding Path=DataContext.AccountAttributes, RelativeSource={RelativeSource AncestorType={x:Type igDP:XamDataGrid}}}" /> <Setter Property="ValuePath" Value="AccountValue" /> <Setter Property="DisplayMemberPath" Value="AccountValue" /></Style>
If you have any questions, please let me know.
Thanks, your syntax works perfect.
One more help please: I have a couple of events on the grid like xgrdMain_RecordUpdated. How do I access the SelectedItem of the above combo-box in code behind?
In your example above, I get the AccountValues in the drop-down and in the associated grid column but I also want to know the AccountId of the SelectedItem in code behind?
In order to access the properties of the currently selected AccountAttribute of the combo editor for any record, I can suggest you introduce the same type of property (AccountAttribute) for the DataItem as well. This way we can bind the AccountAttribute of the DataItem to the respective AccountAttribute from the combo editor's ItemsSource.
public class Item{ ... public AccountAttribute AccountAttribute { get; set; }}
public AccountAttribute AccountAttribute { get; set; }}
<Style TargetType="igE:XamComboEditor"> .... <Setter Property="SelectedItem" Value="{Binding Path=DataItem.AccountAttribute}" /></Style>
Since the AccountAttribute property of the DataItem is of class type, we will need to use AlternateBinding and manually specify which value of the AccountAttribute we would like to visualize in the field.
<igDP:ComboBoxField Label="AccountAttribute" AlternateBinding="{Binding Path=AccountAttribute.AccountValue}">
We can now access the properties of the AccountAttribute for any DataItem (for example the SelectedDataItem of the XamDataGrid):
var accountId = (XDT.SelectedDataItem as Item).AccountAttribute.AccountId;var accountValue = (XDT.SelectedDataItem as Item).AccountAttribute.AccountValue;
Please note that when MVVM is used, the code-behind logic of the view is best to be kept view-specific.I have attached a sample application that demonstrates the approach from above.
Thank you!
Thank you for the feedback.
IN your code,
if (XDT.SelectedDataItem == null) return;
always seems to equate to null. Can you please check. (FYI, I had to demote references to v16.2).
I tested the behavior you have described (with 16.2) in regards to the SelectedDataItem property always being null and I was not able to reproduce it. Only if no record is currently selected, the SelectedDataItem will be null.
If you have integrated the code from the sample within your application, would you please make sure you have also set the SelectedDataItemsScope property of the XamDataGrid to RecordsOrCells.
Okay, in my application, it picks up the correct Item.AccountAttribute for existing rows (i.e. binding seems to work). However, when I add a new row, it passes a null for DataItem.AccountAttribute. It does not save the selected AccountAttribute to Items.AccountAttribute in VM.
Also, this may be related: I have child xamDataGrid bound to an ObervableCollection and the Get{} accessor has following:
return new ObservableCollection<Account>(_data.Where(p => p.AccountId == _accountId));
when _accountId = 0, the above would return an empty collection. When this happens, I am not able to add new row.
Since the behavior in regards to the selection and the binding is strongly dependent on the implementation of the application, it would be best if you could provide me with a sample, where the issue is isolated and reproduced.
Would you also please provide me with detailed steps for reproducing the issue, along with the expected and the actual results from the interaction?
Please see attached app. See main window's code-behind
Thank you for the sample application you have provided.
I tested the behavior you have described inside the window's constructor and when the following lines are executed (they were uncommented by default), I was able to successfully add new records by using the AddNew record functionality at runtime.
/* * * UN-COMMENT THE NEXT TWO LINES AND YOU CAN NOT ADD NEW ROW IN THE GRID * */companies.Data.Add(new Company("Microsoft", "111"));companies.Data.Add(new Company("Intel", "222"));
You mentioned that a property of your DataItem is null when adding it to the XamDataGrid (presuming through the AddNew record). Whenever we type inside a cell of the AddNew record, the XamDataGrid automatically detects that and creates a new record and a new DataItem instance for it by using its parameterless constructor (the RecordAdded event is fired). Since the cell is still in edit mode at this time and the record has not been committed to the XamDataGrid yet, it is expected for the property that corresponds to this cell's value to return null. As soon as we leave the cell (for example enter into the next cell of the same record) or we commit the record, the setter of the property will trigger and the value will be set.The sample application you have provided does not use the XamComboEditor control and this is why I cannot refer to its behavior when using the data from this sample.