The attached patch to AggregateListView partially addresses issue 1613968.
In short, the AmbiguousMatchException is avoided by directly invoking the BindingListView<T>(IList) constructor.
There is a caveat to this approach: it probably won't work well with the synthetic {x}View lists. The {x}View list that is automatically created will be an empty list that is not bound to an underlying list on the real object, as that reference is null, so items added to the list won't be linked to the parent object.
I could have made it return null in this case, but I wasn't sure about that for two reasons: what happens if the underlying list is set to a value, and what side-effect would the non-existent synthetic list have when trying to bind to it.
To cope with this case fully, one could either:
- not make a synthetic view for this property (probably undesirable)
- create an instance of the underlying list and set the list property of the object when the first item is committed to the list.
The second sounds like an ok idea, but I don't have the headspace to dive into it at the moment. I'd appreciate your feedback too.
There is another change in this patch - when the Find method retrieved a null object the Equals comparison failed with a NullReferenceException. I changed it to use object.Equals instead which avoids the exception.
Thanks,
James Telfer
Patch for 1613968.