We are trying to use the DynamicListBase stereotype with WPF view model bound to a listbox. In the view model we are manually calling Model.Remove and passing it our selected item. This works when the factory doesn't throw an exception, however if the factory raises an exception then we have no way of seeing that exception in the UI. The OnError is never called on the view model and a try-catch around the Model.Remove(SelectedItem) never gets hit.
Any ideas on how to handle the exceptions in this case.
Regards
Kevin
The fetch factory throws an exception, and OnError isn't invoked?
Is this a sync or async factory? If it is a sync factory you may need a try..catch around the DoRefresh call, otherwise OnError should surely be invoked.
The fetch factory works ok as expected.
This is a DynamicListBase object and I'm calling Model.Remove(SelectedItem) via a delete action in the UI which directly calls the DataPortal (probably asynchronously). If this fails in the ObjectFactory there is no exception back on the client. OnError is not invoked and I cannot try...catch around it.
We have tried hooking up to the Saved event on the SelectedItem; SelectedItem.Saved += (s,e) => { ...e.Error is null here } This gets called on return from the data portal but e.Error is null.
We have tried hooking up Model.Saved event in the view model: Model.Saved += (s,e) => { e.Error is correct here} this works. However this would suggest a problem somewhere because the Error property on the view model itself is null.
Edit: Also tried DoRemove(SelectedItem) in the view model, no exception
I see. I think this is a mismatch between ViewModelBase and DynamicListBase. Not necessarily a bug either, just a side-effect of the way things work.
DLB doesn't ever get saved itself, and the object saving infrastructure in VMB is all around saving the root object. So the viewmodel's OnSaved and OnError methods (for example) relate to the saving of the root object, which never happens with a DLB.
So I think when your model is a DLB, you'll need to write your own code in the viewmodel to handle the Model.Saved event. If you want, you could set the VMB Error property because its setter is protected.
It still seems a little odd however because we are wiring up the Saved on the Model which is the DLB not the individual items of the collection.
We are also having problems with visual binding. It seems that OnModelChanged is only ever called on population, not when adding/deleting/editing the items, this screws up our UI. We are using Caliburn but I don't think this is affecting the situation as its our Model that is bound to the listbox.
The only solution we can find that behaves correctly is on the Model.Saved to clear the ItemsSource.
var _itemSource = lb.ItemsSource as IList;
lb.ItemsSource = null;
lb.ItemsSource = _itemSource;
I don't think this ViewModelBase can be used easily with DLB stereotype 
.
Kevin
That is possible. The ViewModelBase class was designed around BB and BLB, with support for ROB and ROLB.
DLB is a very different construct, with very different behaviors. And at the time we wrote this code Microsoft didn't have a WPF datagrid control that actually worked with any rich collection. I don't know if they've fixed all the issues or not. The last time I tried using it most things did seem to work, but I didn't build out a comprehensive scenario.
The thing you should ask, is what VMB is getting you. It exists to manage a single root (object or list). That's it. DLB is not that.
So the only thing VMB can give you then is DoRefresh and BeginRefresh behaviors - which are nice, but not all that critical.
My apps typically have a mix of viewmodel types that subclass ViewModel<T> and DependencyObject depending on whether I actually need anything that is in VMB. If I don't need what it offers, I don't subclass VMB.
Copyright (c) Marimer LLC