I've thought about that as well, but I'm not entirely sure how to actually make it work without causing a memory leak. Maybe we can figure it out.
The current model is this:
<csla:ErrorDialog x:Key="dialog" ... />
<csla:CslaDataProvider ... DataChangedHandler="{StaticResource dialog}" ... />
What happens is that the data provider sets the error dialog's DataContext (or Source in SL) property to the data provider, allowing the error dialog to hook the data provider's DataChanged event.
Hooking an event basically sets up a reference from the data provider to the error dialog.
Hmm. Maybe there isn't an issue here. When a form is unloaded, any data provider controls would go away, and so they'd release their reference to the error dialog when the GC destroyed them.
Right now the error dialog maintains a reference to the data provider, but it really wouldn't need to do so, because it could be a passive event listener.
To make this work, the ErrorDialog would need to not hook the event based on the DataContext property - because that's out of my control. It could do it like the SL version, via a Source property.
The only wierd part of this, is that then the Source property wouldn't actually reflect the source. I'd be using a property like a method, and that's pretty lame.
But I could go a step further and drop the Source and DataContext properties (or at least ignore DataContext), and have an actual Register() method, that is invoked by the CslaDataProvider when its DataChangedHandler property is set. Yeah, that'd be a pretty small change from how it works right now, and would still result in an intuitive model.
Of course 3.6.2 is supposed to be feature-complete, and yet if I wait for 3.6.3 then this would be a clear breaking change over the current model... Choices, choices...
Copyright (c) Marimer LLC