Aug 13

Written by:
8/13/2010 7:23 PM 

We this is a classic example of “the early bird gets the worm.” I have been on hiatus for far too long, but have not been idle. I have actually been planning this blog entry for a few weeks, along with another one (more on this in a minute). As it turns out, Michael and Haruhiro where working on pretty much the same concept. They beat me to the finish line with there solution as you can see here: Using the “Hisowa Simple PopUp Behavior” in a DataGrid. Since I took a slightly different approach, I decided to go ahead and post this article.

Additionally, I believe that the more information is examined the best solution will be formed based on pieces of all the information. I want to be very clear, I think the solution described in Haruhiro’s article is great! This article is not being posted to “one up” or discredit Haruhiro’s work in any way and I suggest that if you have not read his post, you should.

Side Note:
The other blog entry I planned on posting is titled “Embrace your Designer” and is along some of the same topics as Michael’s post Silverlight: Why I feel “Design Is The Most Important Thing”. After seeing the articles that Michael and Haruhiro put together, I had to tell Michael to “stop stealing my ideas!” I am seriously starting to wonder if he “chipped” me when I met up with him in Cali.

With that said, “now for something completely different” … well kind of.

I have seen many example and questions regarding how to use a childwindow control when using MVVM. Most examples have either been highly criticized as not “pure MVVM” or overly complicated for a majority of applications. To me, one of the main benefits of MVVM is the simplicity that comes with the pattern. Why then would you want to implement an entire “Childwindow Service Layer” or something equally as complicated? So I started thinking “there has to be an easy way to do this in a MVVM purest fashion.”  That lead to the idea of building a behavior (or action to be specific) that could show a childwindow control. Thanks to the selection of triggers built into Silverlight, the action could be invoked several different ways with no code necessary.

For example, here is a button that is wired to a command on a ViewModel.

 

   <Button x:Name="button"
     Content="Use Command"
     Command="{Binding RequestResponseCommand}" 
     />

 

The command on the ViewModel simply raises an event:

        public void RequestResponse(object param)
        {
            if (this.RequestingResponse != null)
                this.RequestingResponse(this, new EventArgs());
        }

 

Which is handled by an EventTrigger that has the ShowChildWindowAction associated with it:

<i:EventTrigger SourceObject="{Binding}"
                EventName="RequestingResponse">
    <behaviors:ShowChildWindowAction>
        <behaviors:ShowChildWindowAction.ChildWindow>
            <controls:ResponseWindow x:Name="CommandWindow" />
        </behaviors:ShowChildWindowAction.ChildWindow>
    </behaviors:ShowChildWindowAction>
</i:EventTrigger>

So that is all that is needed to display a childwindow; however, that is not very useful in and of itself. Typically we want to know if the window was “cancelled” or “confirmed” and be able to response accordingly. We sometimes also want to have a custom childwindow and to know if any data was changed in the childwindow. This action allows for those scenarios through a set of five properties.

• AttachDataContext: If set to true, attaches the DataContext of the control the EventTrigger is associated with. This is useful if you want to send the ViewModel (or any other DataContext) to the childwindow for binding purposes etc.
  • Note: If you attach the DataContext to the childwindow, any properties changed on that DataContext will change immediately and will not be undone if the window is cancelled.
• ClosedCommand: The ICommand to be executed when the childwindow is closed.
• CommandParameterProperty: The property name of the childwindow control that is used as the parameter of the ClosedCommand when executed.
• ExecuteCommandOnCancel: Specifies if the ClosedCommand should be executed if the DialogResult of the window is “cancelled” or closed.
• ChildWindow: Is a nested childwindow control that is created and shown when the action is invoked. This allows you to build and customize a control that inherits from ChildWindow and use it as the window to be shown.

Here is an example of what the XAML might look like for a button that calls a command only with the DialogResult of a custom ChildWindow control is true and pass the value of the Response property of the ChildWindow to the command:

<behaviors:ShowChildWindowAction
                                    CommandParameterProperty="Response"
                                    ClosedCommand="{Binding UpdateResponseCommand}">
    <behaviors:ShowChildWindowAction.ChildWindow>
        <controls:ResponseWindow x:Name="CommandWindow" />
    </behaviors:ShowChildWindowAction.ChildWindow>
</behaviors:ShowChildWindowAction>

 

Hopefully you are thinking, “Wow this is the greatest thing I have ever seen!” No? Okay, how about something more realistic like, “This seems useful, but how does it work?”

Well, the action was actually fairly simple to build. All of the properties except for ClosedCommand and ChildWindow are standard properties. ClosedCommand is a dependency property that allows for the command to be bound to an ICommand property of your ViewModel.

Note: I have included the source code for an example project so I will not show all of the code here. However, feel free to download the code and browse\use\modify it as you see fit.

In the overridden OnAttached method we handle attaching the DataContext of the associated control and wiring up an event handler to the Closed event of the childwindow if needed.

protected override void OnAttached()
{
    base.OnAttached();
    if (this.AttachDataContext)
        ChildWindow.DataContext = this.AssociatedObject.DataContext;
    if (this.ClosedCommand != null)
        ChildWindow.Closed += new EventHandler(window_Closed);
}

 

The window_Closed method is where we determine if we need to call the ClosedCommand based on the DialogResult and the ExecuteCommandOnCancel values. If so, we create the parameter for the command using reflection (This ones for you Ken! :) ), if a CommandParameter value is specified. Finally we execute the ClosedCommand. Hopefully my C# is clearer than my English:

void window_Closed(object sender, EventArgs e)
{
    ChildWindow window = (ChildWindow)sender;
    if (this.ClosedCommand != null &&
        (this.ExecuteCommandOnCancel ||
            (window.DialogResult.HasValue && window.DialogResult.Value == true)))
    {
        object param = null;
        if (!String.IsNullOrEmpty(this.CommandParameterProperty))
            param = sender.GetType().GetProperty(this.CommandParameterProperty).GetValue(sender, null);
        this.ClosedCommand.Execute(param);
    }
}

The rest of the behavior is pretty straightforward. In the Invoke method we simply call Show on the childwindow and in the OnDetaching method we remove the Closed event handler.

That about wraps it up. I intentionally chose the simplest way to provide the functionality that I required and I am sure there are MANY enhancements that can me made to this behavior. Some of which can probably be found in the HisowaSimplePopUpBehavior. Please do check out that article as well and use the foundations that have been laid here to make something awesome!

I plan on included this control in the OLGCommon project so keep your eye on that, and feel free to submit enhancements.

As always, we value your feedback!

Here is the source code for the example project and behavior: ShowChildWindowExample.zip

Updated 8/14/2010: I have upload a new example project that removed the reference to the OLGCommon assembly and changed the ChildWindow property of the behavior to be a dependency property to allow for binding.