"Kevin Yu [MSFT]" <v-****@online.microsoft.com> wrote in message
news:gd**************@cpmsftngxa10.phx.gbl...
Hi Andrew,
First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you would like the event handlers to
be
GCed automantically. If there is any misunderstanding, please feel free to
let me know.
Based on the code you have provided, I think using WeakReference might
cause the event handler collected by GC at any time, which prevents the
handler from being called. It might make the app unstable.
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
Almost. The situation is this. We have a lot of long running singleton
objects - they are called "Manager" objects. One such object is a data
source that fires off events to anyone who is interested when a given set of
data is modified. There are a series of UI based controls that sit around
and render the data when the user has them on the screen. When the controls
are initialized they are hooked up to the "ChangedData" event via the +=
operator. The code is pretty standard:
dataPublisher.ChangedData += new ChangedDataHandler (...);
of course this means I cannot easily -= from the multicast delegate since I
don't keep a reference to the new ChangedDataHandler around. I could have
written:
handler = new ChangedDataHandler(...);
dataPublisher.ChangedData += handler;
and then during the closing of the control:
dataPublisher.ChangedData -= handler;
However this seems to be a lot of code - and in our specific situation we
would need to keep a LOT of delegate variables around only to be used during
unregistration. Instead, I think it is safe to let the MulticastDelegate
check to ensure that the registered objects actually are still valid, and
keep the reference as a WeakReference so that when the consumer of the data
is disposed/closed it is GC'd.
I'm not sure why this would introduce instabilities.
Thanks
Andrew