What is the suggested pattern for subscribing to messages using IEventAggregator inside view models connected to UserControl views?
See original GitHub issueI have many UserControl
views that are connected to view models that inherit from Screen
. I’d read elsewhere that the recommended pattern for subscribing and unsubscribing to messages using IEventAggregator
is this code:
protected override void OnActivate()
{
EventAggregator.Subscribe(this);
}
protected override void OnDeactivate(bool close)
{
EventAggregator.Unsubscribe(this);
}
Unfortunately, it does not seem that OnActivate
and OnDeactivate
are called for view models connected to UserControl
views. I have been doing the following in the meantime, but I’d really like to call Unsubscribe
explicitly:
protected override void OnViewLoaded(object view)
{
EventAggregator.Subscribe(this);
}
What I want to do is subscribe to messages when the UserControl
loads and unsubscribe when it unloads. Do you have any recommendations?
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Using the event aggregator pattern to communicate between ...
Using the event aggregator pattern to communicate between view models. If you are developing a composite user interface that contains several ...
Read more >c# - MVVM in WPF - How to alert ViewModel of changes in ...
Is there a pattern for alerting the ViewModel of changes in the Model? It would seem to be necessary as (1) conceivably there...
Read more >Simplifying PRISM's EventAggregator - Rachel Lim's Blog
Now I just create the EventMessage, and can use some easy Subscribe/Publish calls anywhere in the application. Simple, easy to remember syntax, ...
Read more >Event Aggregator
In the Prism Library, the EventAggregator allows subscribers or publishers to locate a specific EventBase . The event aggregator also allows for multiple ......
Read more >Why can't ViewModels communicate with each other?
The recommendation seems to be that any communication between ViewModels takes place via a message bus or event aggregator but I can't help...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Excellent, so the lifecycle here for the child view models isn’t being handled by the root view model.
If you’re just instantiating it then it won’t have lifecycle beyond the view being attached / loaded.
If you don’t want your root view model to be a conductor of some sort you can use.
What
ConductWith
does is wire a one time activation / deactivation from the root view model to the child view model.Hmm, yeah, I can see how separation of concerns would be an issue. It does not make sense for the view to be orchestrating this kind of configuration.
I will stick with calling
ConductWith(this)
for now. Thanks for the advice!