I have a collection, say XCollection, derived from businesslistbase
I have successfully bound it ( and its items) to a listbox, and also handle the listchanged handler
coll.ListChanged += coll_ListChanged;
coll = coll.Save();
coll.ListChanged += coll_ListChanged;
If I change a property in one of the items in the collection, the handler is called and the listbox is updated to reflect the change.
On subsequent changes to the item property the handler is called but the listbox is not updated.
The item in the collection is bound to another UI control, as well, for editing.
My assumption is that when the collection is saved, the item is 'orphaned' and the second UI control is pointing to this orphan.
Thanks for any ideas
Your guess is probably correct. You really need to update the DataContext with the result of Save(). The best way to do this is to use a helper control like ViewModel<T> or CslaDataProvider, which will do the work for you.
I've complicated things by using MVVMlite.
The listBoxs DataContext points to a Property ( the actual collection) on a ''CollectionViewModel"
The Edit UI control DataContext points to a Property ( an item from the collection) on a "CollectionItemViewModel"
...and there not connected. So the implication is that both ViewModels' need to reference/update the collection?
Using a CollectionViewModel is fine - I use them all the time now since this is what VS10 generates when you drag an object onto a form to set up data binding in the designer.
But you do need to "cascade" them if you use more than one. There should be a master-detail or parent-child hierarchy with your data context resources.
So having a parent CVS is good, as long as any child CVS or other resources get their data relative to that parent CVS.
Look the the CslaMvvmSl project in the CSLA 4 samples, or the CSLA 4 MVVM video series to see what I'm talking about.
I suspect those techhniques are not incompatible with MVVMlite - though I haven't looked at that framework, so perhaps they require doing something bad. If so, let me know, because I've been mentioning that framework in a good light, but if it requires something that's incompatible with standard VS10 behaviors that would make me change my tune...
I guess I've misunderstood the consequences of ''xColl.Save()" as well.
If I have
XCollection xc = ....
X obj = xc.AddNew();
// Do stuff with obj
How does one update obj?
You need to say xc = xc.Save() so you get the result of the save. Then you can find the new child object in the new xc and update your 'obj' field to reference it.
I normally avoid maintaining references to child objects, and therefore don't need to refresh such references on a save operation - I just maintain a reference to the root object and find other objects in the graph based on the root.
So how would you find the child object again, in that all the editable properties of the child may have changed ( due to user changing them, and then the collection subsequently being saved)
If my Child Editing UI control reference the collection what should it reference - index in the collection?
Honestly I don't know. I'm a little confused about your UI design I guess, as I don't run into this issue - I let data binding do this for me.
If your list is bound to a CVS, the CVS maintains the concept of currency - which item is current. Usually a child edit area of the UI is bound to that current item - thus bound to the appropriate current child. Data binding just makes it all work with no effort on your part.
I think this where I went wrong.
Collection is bound to ListBox.
When user selects Item,create new UIView/ ItemViewModel ( effectively a new window), passing actual Item from the collection, via ListBox.SelectedItem
I think what I should do is pass the item ID and the collection
Copyright (c) Marimer LLC