Within an Infragistics 8.2 UltraComboEditor, we had the following properties set via C#:
DataSource = dataSource;
ValueMember = "Measure";
DisplayMember = "Name";
DataBindings.Add("Value", repository, "Measure");
DataBindings["Value"].DataSourceUpdateMode = DataSourceUpdateMode.OnPropertyChanged;
where dataSource was an array of objects, each with a property Measure, and repository was an object with a property Measure. (Those strings are actually constructor parameters -- just using explicit strings to simplify the example.)
In the course of some refactoring, the name of the property on the objects in the array was changed to BaseEnum (the objects are actually wrapped enumerations, for the curious), but the name of ValueMember above was not changed. And yet, the combo box binding continued to work through initial testing, beta testing, and even after release... until two customers emailed in noting that the combo box was no longer changing the underlying parameter. We were able to dig out the problem by careful study of the source code repository... despite being in the awkward position of not being able to replicate the buggy behavior internally.
Two part question:
What's happening under the hood that
allowed the binding to continue to
function, and/or what might be
unique about those two users that
caused the binding to (correctly)
fail? (O/S version isn't alone the
answer, and we get the unexpectedly functioning
binding on machines that have never
had a version of the software
before, so we're not looking at
rogue binaries).
Are there tools that might have been able to warn us about the misbind, even if something was cleaning up behind?
