Hey there
We discovered a strange behavior of the XamComboEditor (Infragistics.Controls.Editors.XamComboEditor), while it works fine on the other "version" of it (Infragistics.Windows.Editors.XamComboEditor).
In our application, we have an option to refresh the data of the current window. And when doing this the Infragistics.Controls.Editors.XamComboEditor loosing its value in SelectedItem, while the Infragistics.Windows.Editors.XamComboEditor is working fine.
I tracked the difference down to the order how the databound values and references are getting filled. It's a bit complicated to explain, so i made a simple sample with two buttons: "Refresh (NOK)" and "Refresh (OK)".
"Refresh (NOK)" works only correct with Infragistics.Windows.Editors.XamComboEditor, while "Refresh (OK)" works fine for both controls. And the only difference is the order how we fill the objects. When we delete the list of the ItemsSource first, it does not work on Infragistics.Windows.Editors.XamComboEditor. If we do it otherwise, it works on both.We also discovered, that we need to set the databinding mode to "TwoWay" on the property "SelectedValue" of Infragistics.Controls.Editors.XamComboEditor, so the control is pushing the selected value back to it's underlying datasource. So this means, the default mode was changed to "OneWay"? Why?
And last but not least, we switched the control from Infragistics.Windows.Editors.XamComboEditor to Infragistics.Controls.Editors.XamComboEditor, because of the ItemFilters. Only on the control which has those issues, we're able to set the default "IsEditable" behavior from a StartsWith-Filter to a Contains-Filter, how our customers are needing it.
<ig:XamComboEditor.ItemFilters> <ig:ComboItemFilter LogicalOperator="And"> <ig:ComparisonCondition Operator="Contains"/> </ig:ComboItemFilter> </ig:XamComboEditor.ItemFilters>
Is there any other way to achieve this behavior also on Infragistics.Windows.Editors.XamComboEditor? Regards
XamComboEditor_SA_Databinding.zip
Hello and thank you for contacting Infragistics.
1. Continue using the Controls.Editors combos instead of a mix and Windows.Editors combo, but remove it's UpdateSourceTrigger=LostFocus as it is causing most of the issues here; if you plan on using both otherwise its not needed, or please explain why LostFocus would be needed in your application. In addition, I recommend using the shared (Controls.Editors) combo strictly as a standalone editor rather than using the Windows.Editors, which was specifically designed to be used in the XamDataGrid as a combo editor column, which has its own built in filtering (eg. why ItemFilters doesn't exist).
a. Removing the trigger portion of the Controls.Editors combo will address issues between selection item mappings of both controls and make them behave similarly. This ties in what the click events are doing as explain next.
2. In the "not ok" click event the instance of ListItem that is going to exist in the combo doesn't exist yet when setting the Orchestrator Item.
The user clicks "not ok", the Item is set on orchestrator, this fires the setter for Item.ListValue. Then the ListItems collection is then cleared. What this does with the UpdateSourceTrigger=LostFocus will cause SelectedItem/SelectedValue to synchronize but since LostFocus is set the setter on Item.ListValue never updates. This is expected because during this click event, the combo does not have focus so it's never losing it to cause the change. The reason why the WPF combo never changes is because the last property change notification that it receives is the initial setting of Item.ListValue on Orchestrator.
Overall, the LostFocus was causing both controls to be in a knot leading to the inconsistencies.
Let me know if you have any questions.