views:

11

answers:

1

I have a list of models displayed in a listview when the listviewitem is clicked I open a dialog that is bound to the listviewitem's data model and allows the user to edit the various properties.

I am trying to figure how to deal with the ok and cancel buttons. On the one hand if I bind the dialog directly to the listviewitem's model there doesn't seem to be a way to cancel the operation.

If on the other hand I give the dialog a clone (not so hip on this because of the overhead of making my model cloneable) of the model instead of the real one cancel is easy to handle but getting the new data into existing model is pain because then I have to go through and copy all the properties from the clone back into the original model.

I suspect there a good design pattern for this. Any ideas?

+1  A: 

You can change all your bindings to be "explicit", in that they don't automatically push the value back to the source, and then force them to update when the OK button is clicked.

For example, let's bind a TextBox to the model's "Foo" property with an explicit update mode:

<TextBox x:Name="fooEdit" Text="{Binding Foo,UpdateSourceTrigger=Explicit}" />

Then when the OK button is clicked:

BindingExpression be = fooEdit.GetBindingExpression(TextBox.TextProperty);
be.UpdateSource();

This can be a little bit cumbersome if you have lots of controls, but it gives you total control over when the underlying properties are updated from their bound controls.

Update

I should add that you should also look at the IEditableObject interface, which is designed for the scenario you describe. If you can implement that on your model, or an intermediate ViewModel, that makes life much easier.

Matt Hamilton
The explicit update has promise, but the idea of going through every properties ui element and having to name the specific dependency property seems less than ideal.
Mr Bell
I agree. IEditableObject is the better approach. Neither are particularly easy though.
Matt Hamilton
Good answer. IEditableObject is the way to go IMHO. I know it's not hip and cool to have rich base classes anymore but f--- it, I still use my BusinessObject base class which stores property values in a PropertyBag object. The PropertyBag is easily cloneable and BusinessObject implements IEditableObject.
Josh Einstein