>>Not a help (:-{ ) but it raises another issue. If I need to change the source value programmatically (OK I suppose I shouldn't need to do that in a strict MVVM scenario but..) then the UpdateSourceTrigger needs to be 'PropertyChanged'. But if that has to be set on, for example, a TextBox then I'm stuck with the associated behaviour of having the ConvertBack() fire for every keystroke. Fair enough, I suppose, - you can't have it both ways :-{
>
>I'm pretty sure you don't need UpdateSourceTrigger to be 'PropertyChanged' for a programatic update to work. The property changed event is only ignored while the binding operation is in progress. Once it completes the property changed event should force an update like normal. (Or am I not getting what your saying.)

Example:
The default UpdateSourceTrigger for a TextBox is LostFocus(). If I leave it that way and somewhere in code execute: TextBox.Text="Hello World" this is not relayed back to the source - until (and if) the TextBox subsequently loses focus.
To updated the source immediately I need to set the UpdateSourceTrigger to PropertyChanged. If I do that then the source is also updated on every keystroke.

>>>Since your basically storing a view in your model. I think deserializing in the VM would be acceptable.
>>
>>I'm leaning more that way. If the FrameworkElement exists in deserialized form in the VM then I have the option of manipulating properties directly in the VM. Don't see a need for that at the moment (and it may not be a good thing) - guess I need to dwell on this a bit more.
>
>You are doing something a bit strange by persisting the view back to the model. Not that that's anything bad. But it does muddy the waters a bit when you try and logically fit it into an MVVM pattern.
>
>I usually handle persistence by storing the data in a config or similar file separate from the model. I then use attached properties to store and load the persistence data. Persistence in this case is a service that runs separately from the MVVM pattern.
>
>However, based on what you've described so far, I think your solution of storing it back to the model makes perfect sense. In this rather unusual case, the view you are storing is basically part of the models data, so manipulating it in the VM would not seem to violate the pattern. (it might cause problems with unit tests, but I think even that could be worked around.) (I have to play more with unit tests one of these days)

Ditto (s)

>
>The other solution would be to create a custom control that handles deserializing and presenting the data. That might actually fit the MVVM pattern a bit better. Not sure if it would be better or worse for your designers.

The FrameworkElement objects that I'm deserializing completely break MVVM rules (g) .For example the object in question is often a Canvas subclass containing multiple other Framework elements including nested instances of the Canvas subclass itself. ALL UI handling for the Canvas sub-class is handled directly by that class - the VM doesn't get a look in. The class allows re-sizing, rescaling, rotation, group selection, support for Bezier curves, varying the logical tree etc. But given that the VM doesn't actually give a *** about how the user chooses to manipulate the UI I decided that there was no point incurring the overhead of round-tripping every MouseMove, MouseOver etc back to the VM. When the user has finished whatever arcane design they wish to come up with I simply serialize the whole thing to the back end.

It works well but the biggest challenge was ensuring serialization worked OK. Not only in providing my own implementation of ISerializable for objects but also providing surrogates for a lot of .NET types that do not support ISerializable. Debugging failing serialization is a pain.....