Now that you've described it, it makes perfect sense. Thanks Ayende.
I use Paulo's solution now, so that it is no issue for me anymore,
but, just out of curiosity, are there any possible solutions for this?
One (cumbersome) that I can see is to use some kind of interceptor as
you do in your article, in the model make SendPropertyChanged
protected virtual and intercept calls to it. The interceptor, instead
of calling the original SendPropertyChanged, would raise the
PropertyChanged event but with sender being the proxy object.
Could that work?
I don't know neither reflection nor castle proxy stuff well enough to
go and try to do it myself.
On 25 Wrz, 11:04, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> I can most certainly see this being registered on the actual class:
>
> + Method {Void OnPropertyChanged(System.Object,
> System.ComponentModel.PropertyChangedEventArgs)}
> System.Reflection.MethodInfo {System.Reflection.RuntimeMethodInfo}
> + Target {System.ComponentModel.PropertyChangedEventManager}
> object {System.ComponentModel.PropertyChangedEventManager}
>
> And the invocation list contains both of them.
>
> The problem, however, is that the sender object that it sends is different
> than the proxy.
> WPF thinks that it is the proxy that it is handling, while the real object
> behind the scene is raising the event, WPF catch that, but has nothing that
> match this (because the proxy and the real object are different instances).
>
> This is a leaking this issue, I am afraid.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
