If i would need non-modal dialog then i would introduce IDialog and IDialogService same as i did introduce IMessageBoxService etc.

All this may sound too strict but practice learned me that strict naming conventions lead to better code.

Hope this clarifies why i named the classes as i did.

thanks for your feedback!

can you send me on email webmaster [at] roboblob dot com some small example of this bug since i cannot reproduce it in my code it always fires once.
thanks!

http://www.dotnetpatterns.net/entries/15-MVVM-Modal-window-using-MEF

I tried implementing the code to handle the event situation and no go. Same issue.

I consider it a bug because if used as part of a framework, I think it should account for all situations. I was in a hurry when I created the MEF version. But it doesn’t matter if I use shared or nonshared for exporting the viewModel, the same problem exists.

It cost me about 3 hours yesterday trying to figure out why my app was having all kinds of quircky problems and I finally remembered adding this code and it was the culprit.

Great idea but just wanted to save others the hassle I went through yesterday.

The clean up you posted, the Event handlers are different and i think that’s why it doesn’t work. Everything I’ve seen is you have to keep a reference to the handlers you add so you can remove them.

i dont think this is really bug, since in my implementation im always creating new instance of EditUserModalDialogViewModel when im showing the dialog.
So for me Closed event never fires twice since its always different instance (while old one is garbage-collected).
If you are using always same instance of ViewModel then this could be an issue.
Nicer way to handle this would be like this:

public void ShowDialog(IModalWindow view, TDialogViewModel viewModel, Action onDialogClose)
{
view.DataContext = viewModel;
if (onDialogClose != null)
{
EventHandler closedHandler = (sender, e) => onDialogClose(viewModel);

view.Closed += (sender, e) =>
{
view.Closed -= closedHandler;
onDialogClose(viewModel);
};
}
view.Show();
}

Hope it helps!
good luck with your coding.

Also, I have a fix in this sample for the close event I mentioned above.

There’s got to be a better way but this cost me some time tracking it down and had to come up with something and move on.

Thanks.

You continual subscribe to the Close event and never unsubscribe.

Set a breakpoint in your MainPageViewModel at this point.

this.ShowUserCommand =
new DelegateCommand(userInstanceToEdit =>
{
this.modalDialogService.ShowDialog(_editUserDialog, new EditUserModalDialogViewModel
{
User = userInstanceToEdit
},
returnedViewModelInstance =>
{
if (_editUserDialog.DialogResult.HasValue && _editUserDialog.DialogResult.Value)
{
//var oldPos = this.Users.IndexOf(userInstanceToEdit);
//this.Users.RemoveAt(oldPos);
//this.Users.Insert(oldPos, returnedViewModelInstance.User);
}
});
});

Click the Edit button on an item. Each time you click the edit button, it registers for close and this code will fire ever how many times a user has clicked the edit button.

For now, I’ve created a List in my IModalWindow interface that I make the View implement. The code in the ShowDialog function that takes in onDialogClose looks like this.

public void ShowDialog(IModalWindow view, TDialogViewModel viewModel, Action onDialogClose)
{
view.DataContext = viewModel;
if (onDialogClose != null)
{

foreach (var evt in view.ClosedSubscribers)
{
view.Closed -= evt;
}

view.ClosedSubscribers.Clear();

EventHandler ev = (sender, e) => onDialogClose(viewModel);
view.Closed += ev;
view.ClosedSubscribers.Add(ev);
}

view.Show();
}

in my opinion there is nothing wrong with showing multiple levels of modal dialogs from architecture perspective but it is little weird from usability standpoint (but thats another question).
Your code to show dialog from other dialog looks ok except of the part where you are manually creating EditUserModalDialogViewModel (using the new keyword).

I think this should be avoided and you should not manually create instances of classes (except for builtin .net classes) and you should instead always use Service Locator or Dependency Injection patterns to get new instances of your ViewModels.

If you need to manually create a ViewModel then at least ‘ask’ the Service Locator for the instance of the ViewModel and then set it up and use it how you want. Something Like this:

var viewModel = ServiceLocator.Instance.Get();
this.modalDialogService.ShowDialog(dialog, viewModel);

this way you delegate the responsibility of creating Viewmodel to the centralized service (in this case its ServiceLocator) and then if later you have some changes in the constructor of that ViewModel its not your problem, ServiceLocator will handle this for you and you dont need to change your code.

If you want to see how Service Locator works check my code examples im always using it (underneath the covers of Service Locator im using Microsoft Unity IOC to create those instances).

Hope this helps…
Thanks for your feedback.
Cheers!