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.
public interface ITaskDialogService
</span> </span> </span> </span> </span> void ShowTaskDialog(TaskDialogOptions options, Action<TaskDialogResult> callback);
</span></span>public class TaskDialogService : ITaskDialogService
</span> </span> </span> </span> public void ShowTaskDialog(TaskDialogOptions options,
TaskDialogResult result = TaskDialog.Show(options);
if (callback != null)
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).