Event not Firing

Topics: Prism v2 - WPF 3.5
Mar 24, 2010 at 9:27 PM

Hello All,

I have a module in which I have the following:

public void Initialize()
   EventAggregator.GetEvent<LogFileSelectedEvent>().Subscribe(OnLogFileSelected, ThreadOption.UIThread);

private void OnLogFileSelected(string aFilePath)

At another place in the same module, I have the following:

private void OnLogFileDataListBoxSelectionChanged(object sender, SelectionChangedEventArgs, e)

Finally, LogFileSelectedEvent is defined as so:

public class LogFileSelectedEvent : CompositePresentationEvent<string>

I verified with a breakpoint that the subscription line is getting hit before the event is published. However, when I publish the event, OnLogFileSelected() just flat-out doesn't get called. It's inexplicable. It's as if I never subscribed, but I did. A call to CompositePresentationEvent.Contains() confirms the registration. The word "Unsubscribe" does not appear anywhere in my source, so I'm sure I'm not unsubscribing. Can anybody fathom a reason why my handler is not getting called?





Mar 24, 2010 at 10:55 PM

I've had this issue before. This is most likely because the module object you're in doesn't have any external references to it, so it gets garbage collected. EventAggregator uses weak references to the events, so your subscriptions also disappear. This is by design.

Rather than subscribing to the events inside IModule.Initialize(), do it inside your view, or viewmodel.


Mar 25, 2010 at 2:25 PM

You should also make the OnLogFileSelected method public otherwise the EventAggregator won't be able to invoke it.



Mar 25, 2010 at 3:34 PM

Only if he's using Silverlight, I believe. This is because Silverlight doesn't support weak references.

It's OK for the method to be private in a WPF application.

For more info, http://msdn.microsoft.com/en-us/library/dd458915.aspx


Apr 7, 2010 at 10:33 PM

I had this problem as well.  Thanks for the link DashNY.  It contained the solution.  I just thought I'd complete this thread with what worked for me.

First, not all modules need a view.  Sometimes we have modules in our app that have no UI.  They perform specific background functions, handle data, consume and publish events.  So I have noticed that if you Publish an event inside a view, you should subscribe to it there as well.  Or you should subscribe to it on the Constructor overload that includes the ThreadOption in it.  Of course you would subscribe on the UI thread because that is where it is published.  I have yet to confirm this but it seems obvious in the link above.

In modules that don't have a view, the weak reference does get garbage collected unless you use the Subscribe constructor overload that includes the bool SubscriberReferenceKeepAlive option.  This keeps the object alive so the callback can get called.