Reputation: 5384
In MVVM fashion, I have an initial window opening (MainView) with its DataContext (i.e., its viewmodel) being initialized from the code-behind:
XAML:
<Window x:Class="Nova5.UI.Views.MainView" ..............
Code-Behind C#:
public partial class MainView : Window
{
private MainViewModel vm = new MainViewModel(new WPFMessageBoxService());
public MainView()
{
InitializeComponent();
this.Loaded += (s, e) => { this.DataContext = this.vm; };
}
}
From there on out, I use a DialogService to open other windows from UserControls:
XAML:
<Window x:Class="Nova5.UI.Views.WindowDialog"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WindowDialog"
WindowStyle="SingleBorderWindow"
WindowStartupLocation="Manual" SizeToContent="WidthAndHeight">
<ContentPresenter x:Name="DialogPresenter" Content="{Binding .}"/>
</Window>
The ViewModel creates the WindowDialog and associated viewmodel and opens the window.
All is good.
Now the problem. Lets say I have ten usercontrols. Each of these UserControls can be presented by the DialogService. Each of these UserControls can open other UserControls.
What I would like to do is have the MainWindow open UserControl_1. Then have UserControl_1 open UserControl_2. UserControl_1 then needs to close leaving UserControl_2 open. Ofcourse, UserControl_2 can open UserControl_3 after which UserControl_2 disappears leaving only the MainWindow and UserControl_3. In short, each launched UserControl needs to be independent of the control that created it.
I hope this is understandable.
How can this be done? Thanks for any ideas or help.
Upvotes: 0
Views: 380
Reputation: 7944
Typically what you would need to implement here is Dependency Injection
to achieve an Inversion of Control
pattern. Unity
is a good example of an IoC Container to use with WPF (and recommended as part of Prism).
A Dependency Injection container is essentially an in-memory container for items like Service objects or for providing implementation classes based on interfaces which you configure (either through code or configuration XML or other means) and resolve at runtime.
Your ViewModels
for the various Window/Usercontrol objects would be injected with a reference to the DialogService
object at construction time. The DialogService
object may be maintaining a list of the relevant dialogs as they are shown and can co-ordinate the showing/closing of the Windows as necessary based on the calls/logic you code into it.
You could also code the DialogService
as a Singleton pattern and achieve similar results as many in-memory Service layer implementations used in Unity-style composite applications are essentially Singletons enforced through the UnityContainer
.
Upvotes: 1