Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Using the WPF Task Dialog Wrapper in an MVVM Application

0.00/5 (No votes)
1 Dec 2011 1  
How to use the WPF Task Dialog wrapper in an MVVM application.

There's been a mini-flurry lately surrounding my WPF Task Dialog wrapper/emulator combo I blogged and posted about on CodeProject last year. Mostly bug fixes, which I'm happy to try to tackle, and I appreciate that people seem to actually be using it (else how would they find these bugs?). It's given me a little boost of incentive to possibly do some actual new features and improvements.

Since we're on the subject, I thought I would write a bit about how I dogfood my WPF wrapper at work. Typically you're going to be working in an MVVM pattern with WPF applications. As such, it's popular to have ViewModels that consume various services as needed to modularize various pieces of your app. I want my VMs to be able to define and popup Task Dialogs in reaction to various events (or errors), but I want them to remain ignorant of the specific View implementation for Task Dialogs. Additionally, I'd like these Task Dialog calls to be mockable for the purposes of running unit tests and not having to manually click "Close" or whatever on a dialog just to allow the tests to continue.

To do that, I first create a very simple interface and implementation. My example here uses MEF for composition, but you can obviously modify it to fit your IOC container of choice.

C#
using System;
using System.ComponentModel.Composition;

using TaskDialogInterop;

/// <summary>
/// Service that handles displaying task dialogs.
/// </summary>
[InheritedExport]
public interface ITaskDialogService
{
 /// <summary>
 /// Shows a task dialog.
 /// </summary>
 /// <param name="options">A
 ///   <see cref="T:TaskDialogOptions"/> config object.</param>
 /// <param name="callback">An optional callback method.</param>
 void ShowTaskDialog(TaskDialogOptions options, Action<TaskDialogResult> callback);
}

/// <summary>
/// Service that handles displaying task dialogs.
/// </summary>
public class TaskDialogService : ITaskDialogService
{
 /// <summary>
 /// Shows a task dialog.
 /// </summary>
 /// <param name="options"
 /// > A <see cref="T:TaskDialogOptions"/> config object.</param>
 /// <param name="callback">An optional callback method.</param>
 public void ShowTaskDialog(TaskDialogOptions options, 
             Action<TaskDialogResult> callback)
 {
  TaskDialogResult result = TaskDialog.Show(options);

  if (callback != null)
   callback(result);
 }
}

I know, it's incredibly simple. But now our ViewModels will not directly spawn dialogs. Additionally, for our unit tests we can define a special MockTaskDialogService that implements ITaskDialogService, compares the passed in options with expected values and records the results as necessary, and returns a canned response (TaskDialogResult) if desired back to the ViewModel being tested.

Additionally, you can expand on this framework to support things like window ownership. The options could specify an Owner window, but depending on how you do your MVVM your ViewModel may not have a direct reference to either its View or the actual Window that is displaying it (such as in the case where the View is a UserControl).

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here