8/6/2021 Handling Dialogs in WPF with MVVM

Handling Dialogs in WPF with MVVM

[+240] [23] Ray Booysen
[2009-01-18 09:23:11]
[ .net wpf design-patterns mvvm dialog ]
[ https://stackoverflow.com/questions/454868/handling-dialogs-in-wpf-with-mvvm ]

In the MVVM pattern for WPF, handling dialogs is one of the more complex operations. As your view model does not know anything about the view, dialog
communication can be interesting. I can expose an ICommand that when the view invokes it, a dialog can appear.

Does anyone know of a good way to handle results from dialogs? I am speaking about windows dialogs such as MessageBox.

One of the ways we did this was have an event on the viewmodel that the view would subscribe to when a dialog was required.

public event EventHandler<MyDeleteArgs> RequiresDeleteDialog;

This is OK, but it means that the view requires code which is something I would like to stay away from.

Why not bind to a helper object in the View? - Paul Williams

(1) Not sure what you mean. - Ray Booysen
(1) If I understand the question, you don't want the VM popping up dialogs, and you don't want code-behind in the View. Furthermore it sounds like you prefer commands to events. I agree with
all of these, so I use a helper class in the View which exposes a command to handle the dialog. I answered this question on another thread here: stackoverflow.com/a/23303267/420400.
However, the last sentence makes it sound like you don't want any code at all, anywhere in the View. I understand that concern but the code in question is only a conditional, and it's not likely to
change. - Paul Williams
(5) Thje view model should always be responsible for the logic behind the creation of the dialog box, that's the whole reason for its existence in the first place. That said it doesn't (and shouldn't)
do the heaving lifting of creating the view itself. I wrote an article on this subject at codeproject.com/Articles/820324/… where I show that the entire life cycle of dialog boxes can be managed via
regular WPF data binding and without breaking the MVVM pattern. - Mark Feldman

[+130] [2009-05-08 16:36:40] Jeffrey Knight [ ACCEPTED]

I suggest forgoing the 1990's modal dialogs and instead implementing a control as an overlay (canvas+absolute positioning) with visibility tied to a boolean back in the VM.
Closer to an ajax type control.

This is very useful:

<BooleanToVisibilityConverter x:Key="booltoVis" />

as in:

<my:ErrorControl Visibility="{Binding Path=ThereWasAnError, Mode=TwoWay, Converter={StaticResource booltoVis}, UpdateSourceTrigger=PropertyChanged}"/>

Here's how I have one implemented as a user control. Clicking on the 'x' closes the control in a line of code in the usercontrol's code behind. (Since I have my Views in an .exe
and ViewModels in a dll, I don't feel bad about code that manipulates UI.)

(21) Yeah i like this idea also but would like to see some example of this control in terms of how to show it, and retrieve dialog result from it etc. Especially in MVVM scenario in Silverlight. -
Roboblob
(16) How do you prevent the user from interacting with controls underneath this dialog overlay? - Andrew Garrison
(1) Great idea. I created a Popup and controlled visibility by binding to IsOpen. - Zamboni
"How do you prevent the user from interacting with controls ..." ? : private void Window_PreviewKeyDown .... e.Handled = true; - Jeffrey Knight
(2) I don't know if Jeffrey posted his solution anywhere else, but I gave a shot at this. I made my own UserControl and implemented it exactly like Jeffrey's XAML. To get a dialog result, I use
RelayCommand and use CommandParameters to pass on a Yes/No result - snurre
(17) The problem with this approach is that you can't open a second modal dialog from the first one, at least not without some heavy modifications to the overlay system... - Thomas Levesque
And another problem with this approach is using code behind which is decrease maintenance. In all my projects i try to avoid as much as possible using code behind ( besides cases when i have no
choice ). - Jviaches

www.stackprinter.com/export?service=stackoverflow&question=454868 1/10
8/6/2021 Handling Dialogs in WPF with MVVM
(1) @JeffreyKnight when I prevent users from interacting with controls like this - private void Window_PreviewMouseDown .... e.Handled = true;, it also disables the error control, so
the user cant close the error message either. How do I solve this problem? Also, how did you make the rest of the window gray/dull when the error pops up. Thx. I just love this solution. - Joe
Slater
(6) Another problem with this approach is that the "dialog" can't be moved. In our applications, we must have a movable dialog so the user can see what is behind it. - JAB
(16) This approach seems terrible to me. What am I missing? How is this better than a real dialog box? - Jonathan Wood
"How do you prevent the user from interacting with controls underneath this dialog overlay? " instead of the event capturing solution, one could give the dialog a 100% width/height background.
If you don't want it to be visible, though, setting the bg to transparent instead of null will not let any event flow through. However, one still has to pay attention to, for example, key events, in case
a button or something in the dimmed out are has the focus. - Balázs
(2) Another problem is when you have two monitors and want to drag the dialog to the second one. - Vahid
@Vahid: Or anywhere outside of the boundary of the parent window, for that matter. - O. R. Mapper
(7) "canvas+absolute positioning" - what? Why? The mere mention of "absolute positioning" is, in the vast majority of cases, a warning sign that something is very, very wrong. How would an
absolute position be useful if the main window can have any size? Overall, it appears to me that this solution tries hard to replicate every aspect of limited web UIs that use workarounds to look
like they were actual GUIs with true dialog boxes. - O. R. Mapper
1

[+53] [2009-04-17 10:06:28] Roubachof

EDIT: More than 10 years after, I can tell that using a Mediator or any other messaging pattern is a really bad idea at so many levels. Don't do it, just implement Jeffrey's
answer or a IDialogService injected in your view model.

You should use a mediator for this. Mediator is a common design pattern also known as Messenger in some of its implementations. It's a paradigm of type Register/Notify
and enables your ViewModel and Views to communicate through a low-coupled messaging mecanism.

You should check out the google WPF Disciples group, and just search for Mediator. You will be much happy with the answers...

You can however start with this:

http://joshsmithonwpf.wordpress.com/2009/04/06/a-mediator-prototype-for-wpf-apps/

Enjoy !

Edit: you can see the answer to this problem with the MVVM Light Toolkit here:

http://mvvmlight.codeplex.com/Thread/View.aspx?ThreadId=209338

(2) Marlon grech has just posted a brand new implementation of the mediator: marlongrech.wordpress.com/2009/04/16/… - Roubachof
(21) Just a remark : the Mediator pattern was not introduced by the WPF Disciples, it's a classical GoF pattern... (dofactory.com/Patterns/PatternMediator.aspx). Nice answer otherwise ;) -
Thomas Levesque
(12) Please god, don't use a mediator or a darned messenger. That kind of code with dozens of messages flying around becomes very difficult to debug unless you can somehow remember all the
many points in your entire codebase that subscribe to and handle every event. It becomes a nightmare for new devs. In fact, I consider the entire MvvMLight library to be a massive anti-pattern
for its pervasive and unnecessary use of asyncronous messaging. The solution is simple: call a separate dialog service (i.e., IDialogService) of your design. The interface has methods and events for
callbacks. - Chris Bordeman
2

[+35] [2009-04-18 16:41:19] user92541

A good MVVM dialog should:

1. Be declared with only XAML.

2. Get all of it's behavior from databinding.

Unfortunately, WPF doesn't provide these features. Showing a dialog requires a code-behind call to ShowDialog(). The Window class, which supports dialogs, can't be
declared in XAML so it can't easily be databound to the DataContext.

To solve this, I wrote a XAML stub control that sits in the logical tree and relays databinding to a Window and handles showing and hiding the dialog. You can find it here:
http://www.codeproject.com/KB/WPF/XAMLDialog.aspx

It's really simply to use and doesn't require any strange changes to your ViewModel and doesn't require events or messages. The basic call looks like this:

<dialog:Dialog Content="{Binding Path=DialogViewModel}" Showing="True" />

You probably want to add a style that sets Showing. I explain it in my article. I hope this helps you.

(2) That's a really interesting approach to the problem of showing dialog windows in MVVM. - dthrasher
(3) "Showing a dialog requires a code-behind" mmm you can call that in ViewModel - Brock Hensley
I would add point 3 - you are free to bind to other objects within the view. Leaving the dialog's code behind empty does imply that there is no C# code anywhere in the view, and databinding does
not imply binding to the VM. - Paul Williams
3

[+25] [2011-02-10 11:01:10] blindmeis

I use this [1] approach for dialogs with MVVM.

All I have to do now is call the following from my view model.

var result = this.uiDialogService.ShowDialog("Dialogwindow title goes here", dialogwindowVM);

[1] https://stackoverflow.com/questions/3801681/good-or-bad-practise-for-dialogs-in-wpf-with-mvvm

which library does uiDialogService comes from? - aggietech

(1) no library. is just a small interface and implementation: stackoverflow.com/questions/3801681/… . to be fair atm it has some more overloads for my needs :) (height, width, propertysettings
and so on) - blindmeis
4

[+16] [2010-01-21 21:14:17] Roboblob

My current solution solves most of the issues you mentioned yet its completely abstracted from platform specific things and can be reused. Also i used no code-behind only
binding with DelegateCommands that implement ICommand. Dialog is basically a View - a separate control that has its own ViewModel and it is shown from the ViewModel
of the main screen but triggered from the UI via DelagateCommand binding.

See full Silverlight 4 solution here Modal dialogs with MVVM and Silverlight 4 [1]

[1] http://blog.roboblob.com/2010/01/19/modal-dialogs-with-mvvm-and-silverlight-4/

www.stackprinter.com/export?service=stackoverflow&question=454868 2/10
8/6/2021 Handling Dialogs in WPF with MVVM
Just like @Elad Katz's approach, your answer lacks the linked content - please improve your answer by inserting it as that's what's considered a good answer here on SO. Nonetheless, thanks for
your contribution! :) - Yoda
5

[+6] [2010-03-04 00:28:28] Mike Rowley

I really struggled with this concept for a while when learning (still learning) MVVM. What I decided, and what I think others already decided but which wasn't clear to me is
this:

My original thought was that a ViewModel should not be allowed to call a dialog box directly as it has no business deciding how a dialog should appear. Beacause of this I
started thinking about how I could pass messages much like I would have in MVP (i.e. View.ShowSaveFileDialog()). However, I think this is the wrong approach.

It is OK for a ViewModel to call a dialog directly. However, when you are testing a ViewModel , that means that the dialog will either pop up during your test, or fail all
together (never really tried this).

So, what needs to happen is while testing is to use a "test" version of your dialog. This means that for ever dialog you have, you need to create an Interface and either mock
out the dialog response or create a testing mock that will have a default behaviour.

You should already be using some sort of Service Locator or IoC that you can configure to provide you the correct version depending on the context.

Using this approach, your ViewModel is still testable and depending on how you mock out your dialogs, you can control the behaviour.

Hope this helps.

[+6] [2015-03-21 09:25:10] Chris Bordeman

There are two good ways to do this, 1) a dialog service (easy, clean), and 2) view assisted. View assisted provides some neat features, but is usually not worth it.

DIALOG SERVICE
a) a dialog service interface like via constructor or some dependency container:

interface IDialogService { Task ShowDialogAsync(DialogViewModel dlgVm); }

b) Your implementation of IDialogService should open a window (or inject some control into the active window), create a view corresponding to the name of the given dlgVm
type (use container registration or convention or a ContentPresenter with type associated DataTemplates). ShowDialogAsync should create a TaskCompletionSource and
return its .Task proptery. The DialogViewModel class itself needs an event you can invoke in the derived class when you want to close, and watch in the dialog view to
actually close/hide the dialog and complete the TaskCompletionSource.

b) To use, simply call await this.DialogService.ShowDialog(myDlgVm) on your instance of some DialogViewModel-derived class. After await returns, look at properties
you've added on your dialog VM to determine what happened; you don't even need a callback.

VIEW ASSISTED
This has your view listening to an event on the viewmodel. This could all be wrapped up into a Blend Behavior to avoid code behind and resource usage if you're so inclined
(FMI, subclass the "Behavior" class to see a sort of Blendable attached property on steroids). For now, we'll do this manually on each view:

a) Create an OpenXXXXXDialogEvent with a custom payload (a DialogViewModel derived class).

b) Have the view subscribe to the event in its OnDataContextChanged event. Be sure to hide and unsubscribe if the old value != null and in the Window's Unloaded event.

c) When the event fires, have the view open your view, which might be in a resource on your page, or you could locate it by convention elsewhere (like in the the dialog
service approach).

This approach is more flexible, but requires more work to use. I don't use it much. The one nice advantage are the ability to place the view physically inside a tab, for
example. I have used an algorithm to place it in the current user control's bounds, or if not big enough, traverse up the visual tree until a big enough container is found.

This allows dialogs to be close to the place they're actually used, only dim the part of the app related to the current activity, and let the user move around within the app
without having to manually push dialogs away, even have multiple quasi-modal dialogs open on different tabs or sub-views.

A dialog service is much easier, certainly, and what I usually do. It also makes it easy to close the view's dialog from the parent view model, which is necessary when the parent view model is
closing or cancelling. - Chris Bordeman
7

[+5] [2011-11-17 18:16:02] Maxm007

Use a freezable command

<Grid>
<Grid.DataContext>
<WpfApplication1:ViewModel />
</Grid.DataContext>

<Button Content="Text">
<Button.Command>
<WpfApplication1:MessageBoxCommand YesCommand="{Binding MyViewModelCommand}" />
</Button.Command>
</Button>

</Grid>

public class MessageBoxCommand : Freezable, ICommand

{
public static readonly DependencyProperty YesCommandProperty = DependencyProperty.Register(
"YesCommand",
typeof (ICommand),
typeof (MessageBoxCommand),
new FrameworkPropertyMetadata(null)
);

www.stackprinter.com/export?service=stackoverflow&question=454868 3/10
8/6/2021 Handling Dialogs in WPF with MVVM
public static readonly DependencyProperty OKCommandProperty = DependencyProperty.Register(
"OKCommand",
typeof (ICommand),
typeof (MessageBoxCommand),
new FrameworkPropertyMetadata(null)
);

public static readonly DependencyProperty CancelCommandProperty = DependencyProperty.Register(

"CancelCommand",
typeof (ICommand),
typeof (MessageBoxCommand),
new FrameworkPropertyMetadata(null)
);

public static readonly DependencyProperty NoCommandProperty = DependencyProperty.Register(

"NoCommand",
typeof (ICommand),
typeof (MessageBoxCommand),
new FrameworkPropertyMetadata(null)
);

public static readonly DependencyProperty MessageProperty = DependencyProperty.Register(

"Message",
typeof (string),
typeof (MessageBoxCommand),
new FrameworkPropertyMetadata("")
);

public static readonly DependencyProperty MessageBoxButtonsProperty = DependencyProperty.Register(

"MessageBoxButtons",
typeof(MessageBoxButton),
typeof(MessageBoxCommand),
new FrameworkPropertyMetadata(MessageBoxButton.OKCancel)
);

public ICommand YesCommand

{
get { return (ICommand) GetValue(YesCommandProperty); }
set { SetValue(YesCommandProperty, value); }
}

public ICommand OKCommand

{
get { return (ICommand) GetValue(OKCommandProperty); }
set { SetValue(OKCommandProperty, value); }
}

public ICommand CancelCommand

{
get { return (ICommand) GetValue(CancelCommandProperty); }
set { SetValue(CancelCommandProperty, value); }
}

public ICommand NoCommand

{
get { return (ICommand) GetValue(NoCommandProperty); }
set { SetValue(NoCommandProperty, value); }
}

public MessageBoxButton MessageBoxButtons

{
get { return (MessageBoxButton)GetValue(MessageBoxButtonsProperty); }
set { SetValue(MessageBoxButtonsProperty, value); }
}

public string Message

{
get { return (string) GetValue(MessageProperty); }
set { SetValue(MessageProperty, value); }
}

public void Execute(object parameter)

{
var messageBoxResult = MessageBox.Show(Message);
switch (messageBoxResult)
{
case MessageBoxResult.OK:
OKCommand.Execute(null);
break;
case MessageBoxResult.Yes:
YesCommand.Execute(null);
break;
case MessageBoxResult.No:
NoCommand.Execute(null);
break;
case MessageBoxResult.Cancel:
if (CancelCommand != null) CancelCommand.Execute(null); //Cancel usually means do nothing ,so can be null
break;

}
}

public bool CanExecute(object parameter)

{
return true;
}

public event EventHandler CanExecuteChanged;

protected override Freezable CreateInstanceCore()

{
throw new NotImplementedException();

www.stackprinter.com/export?service=stackoverflow&question=454868 4/10
8/6/2021 Handling Dialogs in WPF with MVVM
}
}

This code needs some work, but it is the best idea by far, especially for system dialogs such as file or printer dialogs. Dialogs belong to View if anything does. For file dialogs, the result (file name
selected) can be passed to the inner command as its parameter. - Anton Tykhyy
8

[+3] [2009-01-18 09:36:34] Cameron MacFarland

I think that the handling of a dialog should be the responsibility of the view, and the view needs to have code to support that.

If you change the ViewModel - View interaction to handle dialogs then the ViewModel is dependant on that implementation. The simplest way to deal with this problem is to
make the View responsible for performing the task. If that means showing a dialog then fine, but could also be a status message in the status bar etc.

My point is that the whole point of the MVVM pattern is to separate business logic from the GUI, so you shouldn't be mixing GUI logic (to display a dialog) in the business
layer (the ViewModel).

(2) The VM would never handle the dialog, in my example it would simpy have an event that would require the dialog to fire up and pass back info in some form of EventArgs. If the view is
responsible, how does it pass back info to the VM? - Ray Booysen
Say the VM needs to delete something. The VM calls a method on the View Delete which returns a boolean. The View can then either delete the item directly and return true, or show a
confirmation dialog and return true/false depending on the users answer. - Cameron MacFarland
The VM knows nothing about the dialog but only asked the view to delete something, which the view either confirmed or denied. - Cameron MacFarland
I always thought that the point of MVVM was Model: business logic, ViewModel: GUI logic and View: no logic. Which is somehow contradicted by your last paragraph. Please explain! - David
Schmitt
It asks the view to delete something? Surely the other way around. - Ray Booysen
I'm a beginner with regard to applying the MVVM pattern however I think it is a mistake to think of the ViewModel as a business layer. Instead my understanding is that the ViewModel holds
presentation logic and tracks state necessary for the UI. In my view the Model is the place where business logic and the domain model exists. - jpierson
(2) First it has to be determined if asking for pre-delete confirmation is business logic or view logic. If it is business logic, the DeleteFile method in the model must not do it, but rather return the
confirmation question object. This will include a reference to the delegate that does the actual deletion. If it isn't business logic, the VM must build a VM of the question in the
DeleteFileCommand, with two ICommand members. One for yes and one for no. There are probably arguments for both views, and in RL most of use will probably encounter both. - Guge
9

[+3] [2010-03-21 14:25:17] jbe

An interesting alternative is to use Controllers which are responsible to show the views (dialogs).

How this works is shown by the WPF Application Framework (WAF) [1].

[1] http://waf.codeplex.com
10

[+3] [2011-01-29 18:25:04] Eric Grover

Why not just raise an event in the VM and subscribe to the event in the view? This would keep the application logic and the view seperate and still allow you to use a child
window for dialogs.

11

[+3] [2011-02-06 17:23:16] Elad Katz

I've implemented a Behavior that listens to a Message from the ViewModel. It's based on Laurent Bugnion solution, but since it doesn't use code behind and is more
reusable, I think it's more elegant.

How to make WPF behave as if MVVM is supported out of the box [1]

[1] http://www.codeproject.com/Articles/377094/How-to-make-WPF-behave-as-if-MVVM-is-supported-out

(1) You should include the full code here as that's what SO requires for good answers. Nonetheless, the linked approach is pretty neat, so thank's for that! :) - Yoda
(2) @yoda the full code is quite long, and that's why I'd rather link to it. I have edited my answer to reflect changes and to point to a link that's not broken - Elad Katz
Thanks for the improvement. Nonetheless, it's better to provide code 3 full-page scrolls long here on SO than a link that might be offline someday. Good articles for complex topics are always
pretty long - and I don't see any benefit in opening a new tab, switching to it and scroll there over scrolling on the same page/tab I was on before that. ;) - Yoda
@EladKatz I have seen that you have shared some of your WPF implementation in the link you provided. Do you have any solution for opening a new window from ViewModel? Basically I have
two forms and each has one ViewModel. One user clicks on a button another form pops up and viewmodel1 sends its object to viewmodel2. In form 2 the user can change the object and when they
close the window, the updated object will be sent back to the first ViewModel. Do you have any solution for this? - Ehsan
12

[+2] [2009-04-24 01:39:29] Nikhil Kothari

I think the view could have code to handle the event from the view model.

Depending on the event/scenario, it could also have an event trigger that subscribes to view model events, and one or more actions to invoke in response.

13

[+2] [2010-03-11 21:30:48] mukapu

I had the same situation and wrapped up the MessageBox into a designer invisible control. The details are in my blog

http://geekswithblogs.net/mukapu/archive/2010/03/12/user-prompts-messagebox-with-mvvm.aspx

The same can be extended to any modal dialogs, file browse control etc.

14

[+2] [2019-06-28 07:20:02] dotNET

The standard approach

After spending years dealing with this problem in WPF, I finally figured out the standard way of implementing dialogs in WPF. Here are the advantages of this approach:

1. CLEAN
2. Doesn't violate MVVM design pattern
www.stackprinter.com/export?service=stackoverflow&question=454868 5/10
8/6/2021 Handling Dialogs in WPF with MVVM
3. ViewModal never references any of the UI libraries (WindowBase, PresentationFramework etc.)
4. Perfect for automated testing
5. Dialogs can be replaced easily.

So what's the key. It is DI + IoC.

Here is how it works. I'm using MVVM Light, but this approach may be extended to other frameworks as well:

1. Add a WPF Application project to your solution. Call it App.

2. Add a ViewModal Class Library. Call it VM.
3. App references VM project. VM project doesn't know anything about App.
4. Add NuGet reference to MVVM Light to both projects. I'm using MVVM Light Standard these days, but you are okay with the full Framework version too.

5. Add an interface IDialogService to VM project:

public interface IDialogService

{
void ShowMessage(string msg, bool isError);
bool AskBooleanQuestion(string msg);
string AskStringQuestion(string msg, string default_value);

string ShowOpen(string filter, string initDir = "", string title = "");

string ShowSave(string filter, string initDir = "", string title = "", string fileName = "");
string ShowFolder(string initDir = "");

bool ShowSettings();
}

6. Expose a public static property of IDialogService type in your ViewModelLocator, but leave registration part for the View layer to perform. This is the key.:

public static IDialogService DialogService => SimpleIoc.Default.GetInstance<IDialogService>();

7. Add an implementation of this interface in the App project.

public class DialogPresenter : IDialogService

{
private static OpenFileDialog dlgOpen = new OpenFileDialog();
private static SaveFileDialog dlgSave = new SaveFileDialog();
private static FolderBrowserDialog dlgFolder = new FolderBrowserDialog();

/// <summary>
/// Displays a simple Information or Error message to the user.
/// </summary>
/// <param name="msg">String text that is to be displayed in the MessageBox</param>
/// <param name="isError">If true, Error icon is displayed. If false, Information icon is displayed.</param>
public void ShowMessage(string msg, bool isError)
{
if(isError)
System.Windows.MessageBox.Show(msg, "Your Project Title", MessageBoxButton.OK, MessageBoxImage.Error);
else
System.Windows.MessageBox.Show(msg, "Your Project Title", MessageBoxButton.OK, MessageBoxImage.Information);
}

/// <summary>
/// Displays a Yes/No MessageBox.Returns true if user clicks Yes, otherwise false.
/// </summary>
/// <param name="msg"></param>
/// <returns></returns>
public bool AskBooleanQuestion(string msg)
{
var Result = System.Windows.MessageBox.Show(msg, "Your Project Title", MessageBoxButton.YesNo, MessageBoxImage.Question) == MessageBoxResult.Yes;
return Result;
}

/// <summary>
/// Displays Save dialog. User can specify file filter, initial directory and dialog title. Returns full path of the selected file if
/// user clicks Save button. Returns null if user clicks Cancel button.
/// </summary>
/// <param name="filter"></param>
/// <param name="initDir"></param>
/// <param name="title"></param>
/// <param name="fileName"></param>
/// <returns></returns>
public string ShowSave(string filter, string initDir = "", string title = "", string fileName = "")
{
if (!string.IsNullOrEmpty(title))
dlgSave.Title = title;
else
dlgSave.Title = "Save";

if (!string.IsNullOrEmpty(fileName))
dlgSave.FileName = fileName;
else
dlgSave.FileName = "";

dlgSave.Filter = filter;
if (!string.IsNullOrEmpty(initDir))
dlgSave.InitialDirectory = initDir;

if (dlgSave.ShowDialog() == DialogResult.OK)
return dlgSave.FileName;
else
return null;
}

public string ShowFolder(string initDir = "")

{
if (!string.IsNullOrEmpty(initDir))
dlgFolder.SelectedPath = initDir;

if (dlgFolder.ShowDialog() == DialogResult.OK)
return dlgFolder.SelectedPath;

www.stackprinter.com/export?service=stackoverflow&question=454868 6/10
8/6/2021 Handling Dialogs in WPF with MVVM
else
return null;
}

/// <summary>
/// Displays Open dialog. User can specify file filter, initial directory and dialog title. Returns full path of the selected file if
/// user clicks Open button. Returns null if user clicks Cancel button.
/// </summary>
/// <param name="filter"></param>
/// <param name="initDir"></param>
/// <param name="title"></param>
/// <returns></returns>
public string ShowOpen(string filter, string initDir = "", string title = "")
{
if (!string.IsNullOrEmpty(title))
dlgOpen.Title = title;
else
dlgOpen.Title = "Open";

dlgOpen.Multiselect = false;
dlgOpen.Filter = filter;
if (!string.IsNullOrEmpty(initDir))
dlgOpen.InitialDirectory = initDir;

if (dlgOpen.ShowDialog() == DialogResult.OK)
return dlgOpen.FileName;
else
return null;
}

/// <summary>
/// Shows Settings dialog.
/// </summary>
/// <returns>true if User clicks OK button, otherwise false.</returns>
public bool ShowSettings()
{
var w = new SettingsWindow();
MakeChild(w); //Show this dialog as child of Microsoft Word window.
var Result = w.ShowDialog().Value;
return Result;
}

/// <summary>
/// Prompts user for a single value input. First parameter specifies the message to be displayed in the dialog
/// and the second string specifies the default value to be displayed in the input box.
/// </summary>
/// <param name="m"></param>
public string AskStringQuestion(string msg, string default_value)
{
string Result = null;

InputBox w = new InputBox();

MakeChild(w);
if (w.ShowDialog(msg, default_value).Value)
Result = w.Value;

return Result;
}

/// <summary>
/// Sets Word window as parent of the specified window.
/// </summary>
/// <param name="w"></param>
private static void MakeChild(System.Windows.Window w)
{
IntPtr HWND = Process.GetCurrentProcess().MainWindowHandle;
var helper = new WindowInteropHelper(w) { Owner = HWND };
}
}

8. While some of these functions are generic (ShowMessage, AskBooleanQuestion etc.), others are specific to this project and use custom Windows. You can add more
custom windows in the same fashion. The key is to keep UI-specific elements in the View layer and just expose the returned data using POCOs in the
VM layer.

9. Perform IoC Registration your interface in the View layer using this class. You can do this in your main view's constructor (after InitializeComponent() call):

SimpleIoc.Default.Register<IDialogService, DialogPresenter>();

10. There you go. You now have access to all your dialog functionality at both VM and View layers. Your VM layer can call these functions like this:

var NoTrump = ViewModelLocator.DialogService.AskBooleanQuestion("Really stop the trade war???", "");

11. So clean you see. The VM layer doesn't know nothing about how a Yes/No question will be presented to the user by the UI layer and can still successfully work with
the returned result from the dialog.

Other free perks

1. For writing unit test, you can provide a custom implementation of IDialogService in your Test project and register that class in IoC in the constructor your test
class.
2. You'll need to import some namespaces such as Microsoft.Win32 to access Open and Save dialogs. I have left them out because there is also a WinForms version of
these dialogs available, plus someone might want to create their own version. Also note that some of the identifier used in DialogPresenter are names of my own
windows (e.g. SettingsWindow). You'll need to either remove them from both the interface and implementation or provide your own windows.
3. If your VM performs multi-threading, call MVVM Light's DispatcherHelper.Initialize() early in your application's life cycle.

4. Except for DialogPresenter which is injected in the View layer, other ViewModals should be registered in ViewModelLocator and then a public static property of
that type should be exposed for the View layer to consume. Something like this:

public static SettingsVM Settings => SimpleIoc.Default.GetInstance<SettingsVM>();

www.stackprinter.com/export?service=stackoverflow&question=454868 7/10
8/6/2021 Handling Dialogs in WPF with MVVM
5. For the most part, your dialogs should not have any code-behind for stuff like binding or setting DataContext etc. You shouldn't even pass things as constructor
parameters. XAML can do that all for you, like this:

<Window x:Class="YourViewNamespace.SettingsWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:local="clr-namespace:YourViewProject"
xmlns:vm="clr-namespace:YourVMProject;assembly=YourVMProject"
DataContext="{x:Static vm:ViewModelLocator.Settings}"
d:DataContext="{d:DesignInstance Type=vm:SettingsVM}" />

6. Setting DataContext this way gives you all kinds of design-time benefits such as Intellisense and auto-completion.

Hope that helps everyone.

15

[+1] [2010-04-28 01:33:09] Mark Bostleman

I rolled my own window loader described in an answer to this question:

Managing multiple WPF views in an application [1]

[1] https://stackoverflow.com/questions/1828043/managing-multiple-wpf-views-in-an-application/1828258#1828258
16

[+1] [2011-12-12 17:28:47] surfen

Karl Shifflett has created a sample application for showing dialog boxes using service approach and Prism InteractionRequest approach.

I like the service approach - It's less flexible so users are less likely to break something :) It's also consistent with the WinForms part of my application (MessageBox.Show)
But if you plan to show a lot of different dialogs, then InteractionRequest is a better way to go.

http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/

17

[+1] [2016-10-19 15:30:28] Xav987

I know it's an old question, but when I did this search, I find a lot of related question, but I did not find a really clear response. So I make my own implementation of a
dialogbox/messagebox/popin, and I share it!
I think it is "MVVM proof", and I try to make it simple and proper, but I am new to WPF, so feel free to comment, or even make pull request.

https://github.com/Plasma-Paris/Plasma.WpfUtils

You can use it like this:

public RelayCommand YesNoMessageBoxCommand { get; private set; }

async void YesNoMessageBox()
{
var result = await _Service.ShowMessage("This is the content of the message box", "This is the title", System.Windows.MessageBoxButton.YesNo);
if (result == System.Windows.MessageBoxResult.Yes)
// [...]
}

Or like this if you want more sophisticated popin :

var result = await _Service.ShowCustomMessageBox(new MyMessageBoxViewModel { /* What you want */ });

And it is showing things like this :

18

[0] [2009-01-18 10:07:48] David Schmitt

I was pondering a similar problem when asking how the view model for a task or dialog should look like [1].

My current solution looks like this:

public class SelectionTaskModel<TChoosable> : ViewModel

where TChoosable : ViewModel
{
public SelectionTaskModel(ICollection<TChoosable> choices);
public ReadOnlyCollection<TChoosable> Choices { get; }
public void Choose(TChoosable choosen);
public void Abort();
}

www.stackprinter.com/export?service=stackoverflow&question=454868 8/10
8/6/2021 Handling Dialogs in WPF with MVVM
When the view model decides that user input is required, it pulls up a instance of SelectionTaskModel with the possible choices for the user. The infrastructure takes care
of bringing up the corresponding view, which in proper time will call the Choose() function with the user's choice.

[1] https://stackoverflow.com/questions/295751/how-does-the-presentation-viewmodel-for-a-task-or-dialog-look-like
19

[0] [2009-03-28 08:52:15] Jaco Karsten

I struggled with the same problem. I have come up with a way to intercommunicate between the View and the ViewModel. You can initiate sending a message from the
ViewModel to the View to tell it to show a messagebox and it will report back with the result. Then the ViewModel can respond to the result returned from the View.

I demonstrate this in my blog [1]:

[1] https://web.archive.org/web/20100124103318/http://jacokarsten.wordpress.com/2009/03/27/mvvm-intercommunication-between-view-and-viewmodel
20

[0] [2018-04-05 11:12:30] Mark Feldman

I've written a fairly comprehensive article about this very topic and also developed a pop-in library for MVVM Dialogs. Strict adherence to MVVM is not only possible but
very clean when implemented properly, and it can be easily extended to third-party libraries that don't adhere to it themselves:

https://www.codeproject.com/Articles/820324/Implementing-Dialog-Boxes-in-MVVM

21

[0] [2018-05-07 17:33:49] jogi

Sorry, but I have to chime in. I have been through several of the suggested solutions, before finding the Prism.Wpf.Interactivity namespace in the Prism project. You can use
interaction requests and popup window action to either roll a custom window or for simpler needs there are built in Notification and Confirmation popups. These create true
windows and are managed as such. you can pass a context object with any dependencies you need in the dialog. We use this solution at my work since I found it. We have
numerous senior devs here and noone has come up with anything better. Our previous solution was the dialog service into an overlay and using a presenter class to make it
happen, but you had to have factories for all of the dialog viewmodels, etc.

This isn't trivial but it also isn't super complicated. And it is built in to Prism and is therefore best (or better) practice IMHO.

My 2 cents!

22

[-1] [2012-01-27 10:20:47] Simone

EDIT: yes I agree this is not a correct MVVM approach and I am now using something similar to what is suggested by blindmeis.

One of the way you could to this is

In your Main View Model (where you open the modal):

void OpenModal()
{
ModalWindowViewModel mwvm = new ModalWindowViewModel();
Window mw = new Window();
mw.content = mwvm;
mw.ShowDialog()
if(mw.DialogResult == true)
{
// Your Code, you can access property in mwvm if you need.
}
}

And in your Modal Window View/ViewModel:

XAML:

<Button Name="okButton" Command="{Binding OkCommand}" CommandParameter="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}}">OK</Button>

<Button Margin="2" VerticalAlignment="Center" Name="cancelButton" IsCancel="True">Cancel</Button>

ViewModel:

public ICommand OkCommand

{
get
{
if (_okCommand == null)
{
_okCommand = new ActionCommand<Window>(DoOk, CanDoOk);
}
return _okCommand ;
}
}

void DoOk(Window win)

{
<!--Your Code-->
win.DialogResult = true;
win.Close();
}

bool CanDoOk(Window win) { return true; }

or similar to what is posted here WPF MVVM: How to close a window [1]

[1] https://stackoverflow.com/questions/4376475/wpf-mvvm-how-to-close-a-window/9004041#9004041

(2) I wasn't the downvote, but I suspect it is because the view-model has a direct reference to the view. - Brian Gideon
@BrianGideon, thanks for your comment. I agree this is not a decoupled solution. In fact, I am not using something similar to whar suggested by blindmeis. Thanks again. - Simone

www.stackprinter.com/export?service=stackoverflow&question=454868 9/10
8/6/2021 Handling Dialogs in WPF with MVVM
It's bad form to reach into the view when it's so easy not to. - Chris Bordeman
23

www.stackprinter.com/export?service=stackoverflow&question=454868 10/10