Mar 5, 2014 at 4:27 PM
Edited Mar 5, 2014 at 4:47 PM
I've got a background thread that is raising events every once in a while. I've added a Debug.WriteLine to confirm that this is indeed reaching that bit of code.
I have a separate class that subscribes to this event, but its delegate only gets called once, then never again. Any idea what might be going on? I've used Event Aggregator in a past project without issues, and I'm publishing and subscribing in exactly the
I've found that it works if I set "keepSubscriberReferenceAlive" to true. I never had to do this in my previous project so I don't understand what's different this time around. The subscription is being created in the constructor of a view model (something
I did many times in the previous project), and this VM clearly isn't being destroyed, so why am I having to set this parameter to true? And what are the possible implications of setting this property to true?
It would be helpful if you could describe us how are you Publishing and Subscribing the
Also, you could provide us with a small sample so we could get a better understanding of the scenario and give you better support.
You may find useful information about EventAggregator's
behavior in the following
MSDN Prism Guide
The main implication for keeping the Subscriber Reference
alive would be that the event creates a strong reference, making it neccessary to manually
in order to prevent memory leaks.
One possible cause could be the filtering of the Event
that may be denying every future
handling. Did you configure the filter delegate on that
? If that is the case, how would the filter validation be?
Hi Gabriel, thanks for the reply. I'm publishing and subscribing in the standard way, like this:-
(where "MyEvent" is a POCO class that may or may not contain additional information about the event). I've never had to use any filter predicates when subscribing.
I've been using the EventAggregator fine in another project, but I am doing something a little different with this particular view/view-model (the VM subscribes to the event in its ctr). After the view (and in turn the view-model) are resolved by my IoC container,
the view is then added to the "Children" collection of a FrameworkElement control that lives in my main window (rather than being, typically, added to a Region like my other views). I can only assume that this is somehow causing the problem - perhaps
something is "losing" a reference to the view/view-model once it has been created?
Mar 18, 2014 at 7:32 PM
If the issue you are experiencing is being solved by adding the keepSubscriberReferenceAlive
parameter then it's most likely that the view model is being garbage collected.
Usually you should be able to create and add a view to the visual tree like you are mentioning without problems. However, it might be possible that the view is being separated from its view model if the
property is set to different value. As an example, this is the case when working with
where the DataContext
is set to refer the "model" the view is "rendering."
Please check if there is any element that would change the DataContext
of the view (like if the FrameworkElement you are mentioning modifies the elements that are added to it) and if the view is keeping the view model after being added to the
visual tree. A simple way of testing the later is to add a button to the view with a simple handler in the code-behind, then add a breakpoint in the handler and check the