I am having problems with a basic functionality: I am trying to set the value of an UltraComboEditor in code and the combo is reading the int value as a string and not changing the displayed value to the related display member text. The combo is bound to a dataset for its list items but is not binded to any underlying record field. So with:
mycombo.DataMember = "MyIntID";mycombo.DisplayMember = "MyStringField";mycombo.SetDataBinding(MyDataTable, "");
this displays the list OK. Now, in code after some other field is changed:
mycombo.Value = MyInt;
After this, mycombo displays the number of MyInt and not the related string display member. Also, mycombo.Value shows "10" when the MyInt ==10 (that is to say, the string value.
If I bind the combo to an underlying field, all workds:
mycombo.DataBindings.Add(new Binding("Value", MyDataSet,"MyTable.MyFieldID"));
Now when the record changes, the correct display member is displayed and the mycombo.Value property shows an int and not the string value, e.g., mycombo.Value shows 10 and not "10".
To recap: I want to have an combo that's dropdown is filled with a dataset, but the combo is not bound to any record field; then I want to change the display value in the list in code by setting the Value or whatever field is appropriate with the integer ID of the DisplayMember's key.
Thanks.
I have exactly the same problem. A bound Ultracomboeditor works fine until the myCombo.value is set with a nullable integer (where the underlying datatype is nullable int32). It then converts that to a string.
What is even weirder is that if a different record is selected through the UI, eg. id = 157024 then the myCombo.value returns the string "157024" which fails CType(myCombo.value, Integer?) .
This is really a bug, and the fact that one cannot strongly type the value object is just slack. This means that each (of about 100) combo box needs several lines of inane code to check for strings in a purely numeric bound Id column.
Infragistics 10.2
I agree that if the control is returning the value as a string when it's really a nullable int, that would certainly be a bug.
Can you duplicate this in a small sample project and post it here so we can check it out?