In WPF, using the regular window control to launch child windows makes MVVM and separating a View concern from the ViewModel very difficult.
The problem:
The window control works nicely as a shell for your application, however, launching child windows is problematic because the window control cannot be defined in xaml unless as the root element.
So, if you wanted to launch child windows inside a parent window, you lose the ability to declare these in xaml. This loss means you will not be able to bind to properties in your ViewModel from the view for the purpose of opening/closing a window. Instead you end up doing this imperatively in code which means more code, more thought, more work.
Following is what you end up doing in the most minimalistic cases.
MyWindow window = new MyWindow();
window.ShowDialog();
Adding code such as the above means you are forced to make your ViewModel create instances of your Window and launch them when needed. Clearly something you will not appreciate during testing and since this will provide a tight coupling to a Window control in your ViewModel, it is useless to your tests and eventually breaks your pattern.
What would have been nice instead is if we could do the following :
<my:ModalDialogPopup IsOpen="{Binding FirstPopupIsOpen, Mode=TwoWay}"/>
If we could define our window declaratively in Xam as above, then we use the databinding capabilities in WPF and bind to an FirstPopupIsOpen property in our ViewModel, which is what we are after but sadly not currently possible.
The solution 1: A custom Control that behaved like a Window
Writing a custom control was pretty simple as we make use of the existing Popup control in Wpf. The popup control is pretty wild and requires taming but solves this problem.
Some reasons to design our solution around the existing Popup control:
- The popup control is designed to stay always ontop, which has it's pitfalls but it solves more problems than it brings. More specifically we will want the ability to hide the content under the popup while the popup is in view.
- The popup control can be positioned in so many ways, however what we are after is the ability to define a set of Left, Top coordinates and this is supported out of the box.
- The popup control supports a few animations out of the box. This means we can apply a nice sliding or a fade effect with zero effort.
- The popup control can contain child controls obviously. This is great and serves our purpose very well.
- Enjoy the beauty of an adorner masking the background beneath the ModalDialogPopup.
The solution we end up with is a control like the following :
<my:ModalDialogPopup IsOpen="{Binding FirstPopupIsOpen, Mode=TwoWay}">
<my:ModalDialogPopup.HostedContent>
<ContentControl>
<Grid Height="200" Width="300">
<TextBlock VerticalAlignment="Center"
HorizontalAlignment="Center" FontSize="20">
This is the first modal popup
</TextBlock>
</Grid>
</ContentControl>
</my:ModalDialogPopup.HostedContent>
</my:ModalDialogPopup>
One inherent problem I had not considered while writing this control is that just like the Window control, even with a custom popup control, the limitation to not being able to nest a popup in another popup existed. That's because when showing the child, we are forced to hide the parent for technical reasons that exist in the popup control only(the popup control will always be the top most control).
That means if the parent is larger than the child in dimention, portions of controls in the parent will show and interaction with those pieces becomes possible. When a child popup is launched, we want it to behave as a modal window, so it shouldn't be able to interact with controls in popups beneat it. Sadly the adorner cannot help us here as it cannot cover the “Always ontop” popup.
Ofcourse, the solution to deal with this limitation is to hide the parent when the child is in view, which doesn't help the nesting because if the parent is hidden, then the child will be hidden too! I guess there is a good reason why the Window control in WPF does not allow nesting! Too bad I had to discover this at my own expense.
Even with this shortcomings, in most cases, you can workaround the nesting limitation by designing your solutions with this drawback in mind.
As you can note from the piece of xaml code in the previous code listing above, we have a control that can be defined in our view declaratively that takes content via the HostedContent template. We can also set a Title, and content in it's HostedContent template. In the previous code listing, everytime the property FirstPopupIsOpen evaluates to “true” in our ViewModel, the popup will open.
By default the custom popup provides an OK and Cancel button whose caption/visibility you can set. If you need more customizations you can very well customize its template by providing a custom style. Attemping to supply custom styling is quite simple because the default markup we use is plain and this is intentional since styling is subjective and a trival matter. This enables you to provide custom styling of your own without fighting your way through heavy use of xaml.
If you take a look at the code listing below, all we have is a 3 row grid, one holding the title, the second holding the content you define in the HostedContent template and the last row to hold the OK and Cancel buttons. Simply put, you are in control of the styling and the default style template is prive of any bloated styling markup to distract you.
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:WpfPopup.Controls">
<Style TargetType="{x:Type local:ModalDialogPopup}">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate
TargetType="{x:Type local:ModalDialogPopup}">
<Popup x:Name="dialog" AllowsTransparency="True">
<Grid x:Name="content">
<Grid.RowDefinitions>
<RowDefinition Height="20"/>
<RowDefinition Height="*"/>
<RowDefinition Height="20" />
</Grid.RowDefinitions>
<TextBlock Grid.Row="0" x:Name="title" />
<!-- the hosted content -->
<ContentPresenter x:Name="contentHost"
Grid.Row="1" Margin="5"/>
<StackPanel Grid.Row="2" Orientation="Horizontal"
HorizontalAlignment="Right">
<Button Content="Ok" x:Name="buttonOK"
MinWidth="100" Margin="0,0,5,0" />
<Button Content="Cancel" x:Name="buttonCancel"
MinWidth="100" Margin="0,0,5,0" />
</StackPanel>
</Grid>
</Popup>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
</ResourceDictionary>
And here it is when popped open in the example solution attached to this post :
It's actually quite a minimal control without any bells and whistles and leave the responsibility of styling it in your hands, any way you want. Notice the adorner masking the background and the convenient Ok/Cancel buttons. It's so much simpler to use and easy to test. The amount of work need to set this up compared to a window control (solution 2 below) is minimal.
Surely there is some value for such a control but it is most definitely not a resonable replacement to the Window control entirely, as far as launching child windows is concerned.
Fortunately, the needed work to decouple the existing Window control from the ViewModel could very well be done with a simple interface contract, which brings us to the next solution.
Solution 2 : Decoupling the Window control from the ViewModel
This solution relies on dependency injection to provide proper decoupling of the Window control from the viewmodel. So, we'll need a dependency injection container. You may use any at this point, I'll be using Microsofts Unity. This will also make it a breeze to inject a stub in place of the Window control when Unit testing.
First, let's look at what we're going to construct. It's going to be a series of dialogs. The main Window, and 2 child windows.
The main window :
A child window launched from the main window above :
And finally another child window launched from the child window above :
Ok, now that we know what we are building, lets start. The procedure is simple. We'll start by defining the common functionality we'd normally use from the Window Control in our ViewModel by throwing it into an interface.
public interface IChildWindow
{
void Close();
bool? ShowDialog();
void SetOwner(object window);
bool? DialogResult { get; set; }
}
We do this for each View that is a window control. The reason is simple, in order to decouple the window from the viewmodel, what we are going to do is use constructor injection. By injecting this dependency in the constructor we can ensure easy substitution with fake stubs during testing and everything will just work.
Let's also decouple the window we plan to launch by adding yet another interface :
public interface IChildWindowNested
{
void Close();
bool? ShowDialog();
void SetOwner(object window);
bool? DialogResult { get; set; }
}
And finally, the viewmodel:
public class ChildWindowViewModel
{
private readonly IChildWindow _childWindow;
private readonly IChildWindowNested _childWindowNested;
private ICommand _okCommand;
private ICommand _openCommand;
public ChildWindowViewModel(IChildWindow childWindow,
IChildWindowNested childWindowNested)
{
_childWindow = childWindow;
_childWindowNested = childWindowNested;
}
public ICommand OpenCommand
{
get
{
return _openCommand ?? (_openCommand =
new DelegateCommand(OpenClick));
}
}
public ICommand OkCommand
{
get
{
return _okCommand ?? (_okCommand =
new DelegateCommand(OkClick));
}
}
private void OpenClick()
{
_childWindowNested.SetOwner(_childWindow);
_childWindowNested.ShowDialog();
}
private void OkClick()
{
_childWindow.DialogResult = true;
_childWindow.Close();
}
}
As you can notice in the above class, we are passing 2 interfaces in the constructor. The first is the window using this viewmodel : ChildWindow.xaml and the second is the window it will launch : ChildWindowNested.xaml
The relationship between these two windows is a typical parent child relationship, ChildWindow.xaml is the parent, while ChildWindowNested.xaml is the child being launched.
The reason we pass IChildWindow, the parent window in this case is because :
- We need to tell the child Window we are launching who it's owner is. That way we can nicely position the child window relative to it's parent.
- As this is the viewmodel of ChildWindow.xaml, we will also want to handle closing this parent window when it's Ok and Cancel buttons are clicked.
The reason we pass IChildWindowNested, the child window we are launching is because:
- We want to launch this dialog based on an action in ChildWindow.xaml
- To decouple the window from the viewmodel, because we will be using dependency injection to set up this dependency on the window control.
Now the codebehind for ChildWindow.xaml :
public partial class ChildWindow : Window, IChildWindow
{
private readonly IUnityContainer _container;
public ChildWindow()
{
InitializeComponent();
_container = UnityContainerResolver.Container;
var childWindowNested =
_container.Resolve<IChildWindowNested>();
DataContext = new ChildWindowViewModel(this,
childWindowNested);
Closing += ChildWindowClosing;
}
#region IChildWindow Members
public void SetOwner(object window)
{
Owner = window as Window;
}
#endregion
private void ChildWindowClosing(object sender, CancelEventArgs e)
{
e.Cancel = true;
Visibility = Visibility.Hidden;
}
}
We can setup the viewmodel binding to the DataContext in several ways however doing this in the codebehind of the view as in the sample code above is the most flexible of all solutions especially if your moving beyond the typical blog post samples.
At the end of the day, it's only a matter of opinion and what's important is that there is no dependency impeding you from testing your application. And ofcourse that it does not break your pattern. In our case, it's both convenient as we want to pass a reference of the current window to the viewmodel and at the same time, we want to do it in a very decoupled way to help us test our viewmodel.
Also note that we are hooking into the closing handler and cancelling the default close behavior of the Window control. That's because once a window is closed, we cant reopen it and we'll need to create a new instance of the window.
Certainly this depends on your use case. For me, my requirements are such that I need to reuse the window being closed. This works nicely.
What about dependency injection and how is our Unity container setup ? It's quite simple in this case. For this sample code, I just created a singleton that registers all dependencies with the container :
public class UnityContainerResolver
{
private static IUnityContainer _container;
private UnityContainerResolver()
{
}
public static IUnityContainer Container
{
get
{
if (_container == null)
{
_container = new UnityContainer();
RegisterTypes();
}
return _container;
}
}
static void RegisterTypes()
{
_container.RegisterType<IMainWindow, MainWindow>();
_container.RegisterType<IChildWindow, ChildWindow>();
_container.RegisterType<IChildWindowNested,
ChildWindowNested>();
}
}
That's it. By registering dependencies with a dependency container, it becomes so easy to inject fakes in our viewmodel in place of the real object. In our case, when testing, we can make a different registration by mapping to our fake mock objects and this is relatively simple when using a dependency container :
static void RegisterTypes()
{
_container.RegisterType<IMainWindow, MockMainWindow>();
_container.RegisterType<IChildWindow, MockChildWindow>();
_container.RegisterType<IChildWindowNested,
MockChildWindowNested>();
}
And MockChildWindow having enough code to satisfy the contract of IChildWindow.
public class MockChildWindow : IChildWindow
{
public object Owner { get; set; }
public void Close()
{
//
}
public bool? ShowDialog()
{
return true;
}
public void SetOwner(object window)
{
Owner = window;
}
public bool? DialogResult
{
get;
set;
}
}
The viewmodel itself only uses methods exposed by the contract so we are safe to use a fake object as above for testing.
I have added a test app containing the custom popup and all code discussed here. Be sure to check it out!
Download sample application
