Simple Dialog Service in Silverlight

I noticed on the forums there are a lot of users not comfortable with asynchronous programming who struggle a bit in Silverlight with getting their arms around the concept of a dialog box. In other environments, you can simply shoot out a dialog, wait for the response, and continue. In Silverlight, of course, the action is asynchronous. I would argue it should be this way most of the time.

The problem is that many people tend to take the approach of trying to force the process into a synchronous one, instead of changing the way they think and approach the application. There is a reason why processes are asynchronous in Silverlight. There is one main UI thread, and a blocking process would block the entire thread and effectively freeze the Silverlight application. Having the process asynchronous allows you to continue to render graphics elements, perform actions in the background, even display a soothing animation while you await the user’s response.

I spoke to a more highly decoupled approach in a post awhile ago that was more an experiment with the event aggregator: Decoupled Child Window Dialogs with Silverlight and PRISM. Here, I want to show the more straightforward approach.

The first step is to choose what the dialog will be displayed with. In Silverlight, the ChildWindow makes perfect sense because it is a modal dialog that appears, waits for the user response, and then saves the response. We’ll create a new child window and call it Dialog.xaml. It looks like this:

<controls:ChildWindow x_Class="SimpleDialog.Dialog"
           Width="400" Height="300" 
           Title="{Binding Title}">
    <Grid x_Name="LayoutRoot" Margin="2">
            <RowDefinition />
            <RowDefinition Height="Auto" />
        <TextBlock TextWrapping="Wrap" Grid.Row="0" Text="{Binding Message}"/>
        <Button x_Name="CancelButton" Content="Cancel" Click="CancelButton_Click" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,0,0" Grid.Row="1" />
        <Button x_Name="OKButton" Content="OK" Click="OKButton_Click" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,79,0" Grid.Row="1" />

You’ll notice I made very few changes from the provided template. The key here is that I changed the title to bind with the Title property, and added a text block to display a message from the Message property.

Because this is a simple dialog box, I really feel a view model is overkill. Some purists will insist on this but I argue the functionality is simple enough that we don’t need the extra overhead. We’ll be using an interface to the solution down the road that we can easily unit test, and this makes the dialog function (which lives entirely in the UI) a self-contained implementation.

Next, I made a few changes to the code behind:

public partial class Dialog : ChildWindow
    public Action<bool> CloseAction { get; set; }

    public static readonly DependencyProperty MessageProperty = DependencyProperty.Register(

    public string Message
        get { return GetValue(MessageProperty).ToString(); }
        set { SetValue(MessageProperty, value); }

    public Dialog()
        DataContext = this;

    public Dialog(bool allowCancel)
        : this()
        CancelButton.Visibility = allowCancel ? Visibility.Visible : Visibility.Collapsed;

    private void OKButton_Click(object sender, RoutedEventArgs e)
        this.DialogResult = true;            

    private void CancelButton_Click(object sender, RoutedEventArgs e)
        this.DialogResult = false;           

Again, not too many changes here. I added the Message property as a dependency property, and in the constructor I set the data context to itself. This allows me to bind to the title and message. This allows us to simply set the message on the dialog and have it appear. I also added an action for it to retain when closed. This will store a callback so that it can notify the host of the user’s final actions. Finally, there is a method that conditions whether or not there is the option for a cancel button. For alerts, we’ll simply show an OK button. For confirmations, we’ll show the Cancel button as well.

Next is a simple interface to the dialog. Nothing in our application should know or care how the dialog is displayed. There is simply a mechanism to display the dialog and possibly acquire a response. The interface looks like this:

public interface IDialogService
    void ShowDialog(string title, string message, bool allowCancel, Action<bool> response);

In our simple demonstration, I’m allowing for a title, a message, whether or not you want to show the cancel button for confirmations, and then an action to call with the response. With this simple interface we have all we need to wire in unit tests for services and controls that rely on the dialog. You can create your own mock object that implements the IDialogService interface and returns whatever response you want to stage for the unit test.

In the production application, we’ll need to show a real dialog. Here is the class that handles it:

public class DialogService : IDialogService
    #region IDialogService Members

    public void ShowDialog(string title, string message, bool allowCancel, Action<bool> response)
        var dialog = new Dialog(allowCancel) {Title = title, Message = message, CloseAction = response};
        dialog.Closed += DialogClosed;

    static void DialogClosed(object sender, EventArgs e)
        var dialog = sender as Dialog;
        if (dialog != null)
            dialog.Closed -= DialogClosed; 
            dialog.CloseAction(dialog.DialogResult == true);


This is fairly straightforward. When called, we’ll create an instance of the dialog and set the various properties, including the callback. We wire into the closed event. Whether the user responds by clicking a button or closing the dialog, this event is fired.

There is a reason why we are using the snippet DialogResult == true. The result is null-able, so we cannot simply refer to the value itself and make a true/false decision (null, by definition, is unknown). So only if the user explicitly provides a true response by clicking the OK button will the expression evaluate to true. Otherwise, we assume false and call back with the response.

There is also a very important step here that is important to recognize. Many beginners fail to catch this subtle step and end up with memory leaks. When the closed event fires, the dialog box effectively closes. Typically, there would be no more references to it (it is no longer in the visual tree) and it can be cleaned up by garbage collection. However, there is a fatal mistake you can make that will result in the dialog box never going away.

That mistake has to do with how events work. When we register the closed event, the thought process is often that the dialog box has an event, and therefore knows to call back to the dialog service. This is flawed, however. A reference exists from the dialog service to the dialog box. The dialog service effectively “listens” for the event, and when it is raised, will respond. We must unregister the event like this:

dialog.Closed -= DialogClosed;

Otherwise, the reference remains and garbage collection will never claim the dialog box resource. In a long running application, this could prove to be a serious flaw. This line is not included in the code sample download. I encourage you to run with windbg or even step through debug in Visual Studio and watch the object graphs and reference counts as you fire multiple dialogs. Then, add the line of code above and re-run it to see the difference when you appropriately unregister the event.

To demonstrate the use of the service, I put together a quick little page with a few buttons and a text block:

<UserControl x_Class="SimpleDialog.MainPage"
    xmlns_d="" xmlns_mc="" 
    mc_Ignorable="d" d_DesignWidth="640" d_DesignHeight="480">
  <Grid x_Name="LayoutRoot">
        <StackPanel Orientation="Vertical">
            <Button x_Name="ToggleEnabled" 
                    Margin="5" Width="Auto" Content="Disable Dialog Button" Click="ToggleEnabled_Click"/>
            <Button x_Name="DialogButton" 
                    Margin="5" Width="Auto" Content="DialogButton" Click="DialogButton_Click"/>
            <TextBlock x_Name="TextDialog" 
                       Margin="5" Width="Auto" Text="Result Will Show Here"/>

The first button is a toggle to enable or disable the second button. It shows how to receive a response and act based on the user input. If the user confirms, the button is toggled to enabled or disabled. If the user cancels or closes the dialog, the state of the button remains the same. The second button raises a dialog, and simply shows the result. Because it is an alert dialog, we know a false response indicates the user closed the window instead of clicking OK.

Here is the code behind:

public partial class MainPage : UserControl
    private bool _toggleState = true;
    private readonly IDialogService _dialog = new DialogService();

    public MainPage()

    private void ToggleEnabled_Click(object sender, RoutedEventArgs e)
            _toggleState ? "Disable Button" : "Enable Button",
                ? "Are you sure you want to disable the dialog button?"
                : "Are you sure you want to enable the dialog button?",
            r =>
                    if (r)
                        _toggleState = !_toggleState;
                        DialogButton.IsEnabled = _toggleState;
                        ToggleEnabled.Content = _toggleState ? "Disable Dialog Button" : "Enable Dialog Button";

    private void DialogButton_Click(object sender, RoutedEventArgs e)
            "Confirm This",
            "You have to either close the window or click OK to confirm this.",
            r => { TextDialog.Text = r ? "You clicked OK." : "You closed the dialog."; });

Notice that in the click events, we call to the dialog service and pass it anonymous methods for the return types. We could point to real methods on the class as well. The important part is to change your thought process from synchronous step one => wait => step two to asynchronous step one => delegate to step two, then step two is called when ready.

In a production application, instead of creating an instance of the dialog box, we would either register it with a container:


And inject it in a constructor, or use something like MEF and import the dialog service:

public IDialogService Dialog { get; set; }

We would simply flag the implementation as the export or use the InheritedExport attribute on the interface itself.

Click here to download the source code for this example.

Jeremy Likness

Sales team

You can email us at or click below:

Sales team

Main Contacts



Headquarters & Beaverton Data Centers:

9705 SW Sunshine Court, Beaverton, OR 97005

Portland, OR: 1.503.222.2202

Toll-Free: 1.800.903.4852

Fax: 1.503.646.1400

Support & Technical Assistance Command Center (TACC) Hours: 24x7x365

Access Web Help Desk: WHD Login

Contact Support: Email Support

Legacy Services Support

EasyStreet Technical Support Site

Legacy Infinity Internet Technical Support Site

PO Box 2518, Portland, OR 97208
Contact Billing:
Email Accounting

BIlling Portal

Stay Connected

Newsletter, news flash, events, maintenance notices, and email preferences.


We deliver solutions that accelerate the value of Azure.

Ready to experience the full power of Microsoft Azure?

Start Today

Blog Home

Stay Connected

Upcoming Events

All Events