Communcate between TreeView, ListView and Details in separate regions

Topics: Prism v2 - WPF 3.5
Aug 23, 2009 at 4:44 PM

Could someone confirm that I'm going about this the right way, please.

I have a Shell with several regions including a MainRegion.  One View that is added to the MainRegion has a a ViewModel as its DataContext and hosts five more regions.  Three of these regions are used for TreeViewViews, ListViewViews and DetailsViews.  Each of these has its own ViewModel as its DataContext.  All of the Views come from the same Module.

I'd like classic behaviour: I select a folder in the TreeViewView and get its contents in the ListViewView.  I select an item in the ListViewView and get its properties in the DetailsView.

I've created an attached behaviour (using Damian Schenkelman’s Snippet) for the TreeViewItems so that I can run a DelegateCommand when the TVI is selected.  The plan is to use this to send an event via the EventAggregator and allow the ListViewViewModel to pick it up.  (And then do the same again to link ListViewItems to the DetailsView.  Is this the right way to do things?

Aug 25, 2009 at 8:54 PM

Hi ssg31415926, 

Though I don't know the whole application, the scenario you describe seems to be the ok.
Using the event aggregator to communicate between different views is fine, but  if all view are in the same module and the events that you are going to publish are not going to be used by other modules, you might also use .net events (maybe using a controller at module level to coordinate interaction). 

Hope it helps! 

Matias Bonaventura

Aug 27, 2009 at 4:26 AM

I have a similar set up *kind of*.  To simplify the point lets just say I have a shell with two regions. Ther first hosts what I call the 'navigator' essentailly my tree veiw for navigation. The navigator lives in its own module. I also have a main region that displays view related to the navigator selection. When a tree view item is clicked I raise an event using the event aggregator. I have a ViewManager class that subscribes to the event and acts as a controllor of sorts. It inspects the event payload, and decides what screen should be injected into the main region. So conceptually I am using a similar pattern to what you are describing here. I can tell you that it works well.

However if you are doing this all in one module there is no real reason to not used a simple command the event aggregator could be overkill as you are not doing module to module communication.

Good luck,


Aug 28, 2009 at 11:56 AM

Thanks for your replies.  I think I was suffering a bit from region-itis.  It was the classic case that I had a hammer (Regions) and so everything I looked at looked like a nail: I had more regions than I needed, so I'm taking another look at it.  I've also had a play with EventAggregator and it does work quite well.

Oct 7, 2009 at 11:33 AM

Hi Brette

The setup you have explained is exactly what i'm looking to do in my app, can you point me to an example or blog that would explain this in more detail as i'm really new to this.