>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.

Wouldn't TextBox.Text="Hello World" remove the binding on TextBox.Text and replace it with the string "Hello World"? Since the binding on TextBox.Text is now gone, the source would never be updated.

Or am I still not following?

>>
>>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.

I differentiate between a view and a control. I would consider your subclasses to be controls, handling events in a control seems completely correct to me. It isn't till you add the control to a view that the MVVM pattern kicks in.

>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.....

Yep... that would be a pain.