Dear all,
I'm unsure if this is a bug or a wrong use on my side.
I'm having troubles in production that - unfortunately - I'm not able to reproduce yet.
This CSLA code is deployed in a Silverlight Client.
The stack trace indicates that the code is inside CSLA:
at System.ThrowHelper.ThrowArgumentOutOfRangeException()
at System.Collections.Generic.List`1.get_Item(Int32 index)
at System.Collections.ObjectModel.Collection`1.get_Item(Int32 index)
at Csla.DynamicListBase`1.SaveItem(Int32 index)
at Csla.DynamicListBase`1.Csla.Core.IParent.ApplyEditChild(IEditableBusinessObject child)
at Csla.Core.BusinessBase.AcceptChangesComplete()
at Csla.Core.UndoableBase.AcceptChanges(Int32 parentEditLevel)
at Csla.Core.BusinessBase.ApplyEdit()
at Csla.Core.BusinessBase.System.ComponentModel.IEditableObject.EndEdit()
at MyCompany.ViewModel.ActivitiesCollectionItemVm.System.ComponentModel.IEditableObject.EndEdit()
My custom VM code is implementing IEditableObject.EndEdit and calls it on a Dynamic List Base collection.
Are there any situations in which I should not 'allow' this EndEdit to be propagated?
Is anyone else facing the same trouble?
I'm using CSLA 4.3.10.
Regards,
Gilles
If you are going to interact with a dynamic list, you must call the IEditableObject methods on the business object exactly as if it were Windows Forms data binding calling those methods.
In other words, we ensure those methods work with standard data binding, most notably WinForms, but also WPF. If you are the one calling those methods from your viewmodel, then you must understand and follow the exact same calling conventions.
Copyright (c) Marimer LLC