Inspection, Default Services and Items (WF4 EditingContext Intro Part 6)

This part 6 of my 6  part series on the EditingContext.

Introduction

Sharing Functionality between Designers 

Host provided capabilities  

Providing callbacks for the host 

Subscription/Notification engine

Inspection, Default Services and Items (you are here)

I want to wrap up this series of posts by posting some code for an activity designer that functions more as a diagnostic tool, and will display all of the Items and services of the EditingContext within the designer.  This will be useful from an investigation perspective, and hopefully as a diagnostic tool.  We will use this to help us understand what are the services that are available out of the box in VS, as well as in a rehosted application. 

We first need to create an empty activity to attach a designer to.

 using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;
using System.ComponentModel;

namespace blogEditingContext
{
    [Designer(typeof(DiagnosticDesigner))]
    public sealed class Diagnosticator : CodeActivity
    {
        // Define an activity input argument of type string
        public InArgument<string> Text { get; set; }

        // If your activity returns a value, derive from CodeActivity<TResult>
        // and return the value from the Execute method.
        protected override void Execute(CodeActivityContext context)
        {
            // Obtain the runtime value of the Text input argument
            string text = context.GetValue(this.Text);
        }
    }
}

Now, let’s create our designer.  We could do fancy treeviews or object browser style UI’s, but as this is a blog post, I want to provide you with the basics, and then let you figure out how that is most useful to you.  So, we will just create a designer that writes out to debug output the relevant information. 

 <sap:ActivityDesigner x:Class="blogEditingContext.DiagnosticDesigner"
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:sap="clr-namespace:System.Activities.Presentation;assembly=System.Activities.Presentation"
    xmlns:sapv="clr-namespace:System.Activities.Presentation.View;assembly=System.Activities.Presentation">
  <Grid>
        <Button Click="Button_Click">Debug.WriteLine Context Data</Button>
    </Grid>
</sap:ActivityDesigner>

And now the code

 using System.Diagnostics;
using System.Linq;
using System.Windows;

namespace blogEditingContext
{
    // Interaction logic for DiagnosticDesigner.xaml
    public partial class DiagnosticDesigner
    {
        public DiagnosticDesigner()
        {
            InitializeComponent();
        }

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            // the goal here is to output meaningful and useful information about 
            // the contents of the editing context here. 
            int level = Debug.IndentLevel;
            Debug.WriteLine("Items in the EditingContext");
            Debug.IndentLevel++;
            foreach (var item in Context.Items.OrderBy(x => x.ItemType.ToString()))
            {
                Debug.WriteLine(item.ItemType);
            }

            Debug.IndentLevel = level;
            Debug.WriteLine("Services in the EditingContext");
            foreach (var service in Context.Services.OrderBy(x => x.ToString()))
            {
                Debug.WriteLine(service);
            }
        }
    }
}

Let’s break this down.  The work here happens in the button click where we simply order by types’ string representations and output them to the debug writer (a more robust implementation might use a trace writer that could be configured in the app, but for this purpose, this will be sufficient.

So, what output do we get?

VS Standard Services and Items

We determine this by using the activity in a freshly opened WF project

Items

Services

Basic Rehosted Application Standard Services and Items

Items

Services

Comparison Table View

Conclusion

This wraps up our series on the editing context.  We’ve gone through the basics of why we need it, what we can do with it, and then we moved how to use it, from both the very simple to the very complex.  We’ve finished with a diagnostic tool to help understand what all items I can bind to.

What’s Next From Here?

A few ideas for the readers who have read all of these:

• Wire up a few attached properties to reflect back through to some interesting data (like if it is selected).  These attached properties could then be used directly by your UI (via the binding in XAML) to let your designers display and react to changes in the data
• Think about ideas for services you might want to add in VS without depending on an activity to inject it (and send me mail, I am trying to compile a list of interesting things)
• Are there service/item implementations you want to override in VS?
• Is there a service/item you expect to see that is not there?

Thanks for now!

blogEditingContext.zip