Matt W's Windows Workflow Place : wf4

Swiss Cheese and WF4, or, An Introduction to ActivityAction

mwinkle — Thu, 24 Dec 2009 01:46:49 GMT

One common scenario that was often requested by customers of WF 3 was the ability to have templated or “grey box” or “activities with holes” in them (hence the Swiss cheese photo above). In WF4 we’ve done this in a way that way we call ActivityAction

Motivation

First I’d like to do a little bit more to motivate the scenario.

Consider an activity that you have created for your ERP system called CheckInventory. You’ve gone ahead and encapsulated all of the logic of your inventory system, maybe you have some different paths of logic, maybe you have interactions with some third party systems, but you want your customers to use this activity in their workflows when they need to get the level of inventory for an item.

Consider more generally an activity where you have a bunch of work you want to get done, but at various, and specific, points throughout that work, you want to allow the consumer of that activity to receive a callback and provide their own logic to handle that. The mental model here is one of delegates.

Finally, consider providing the ability for a user to specify the work that they want to have happen, but also make sure that you can strongly type the data that is passed to it. In the first case above, you want to make sure that the Item in question is passed to the action that the consumer supplies.

In wf3, we had a lot of folks want to be able to do something like this. It’s a very natural extension to wanting to model things as activities and composing into higher level activities. We like being able to string together 10 items as a black box for reuse, but we really want the user to specify exactly what should happen between steps 7 and 8.

A slide that I showed at PDC showed it this way (the Approval and Payment boxes represent the places I want a consumer to supply additional logic):

Introducing ActivityAction

Very early on the release, we knew this was one of the problems that we needed to tackle. The mental model that we are most aligned with is that of a delegate/ callback in C#. If you think about a delegate, what are you doing, you are giving an object the implementation of some bit of logic that the object will subsequently call. That’s the same thing that’s going on with an ActivityAction. there are three important parts to an ActivityAction

The Handler (this is the logic of the ActivityAction)
The Shape (this determines the data that will be passed to the handler)
The way that we invoke it from our activity

Let’s start with some simple code (this is from a demo that I showed in my PDC talk). This is a timer activity which allows us to time the execution for the contained activity and then uses an activity action to act on the result.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Activities;

using System.Diagnostics;

namespace CustomActivities.ActivityTypes

    public sealed class Timer : NativeActivity<TimeSpan>

        public Activity Body { get; set; }

        public Variable<Stopwatch> Stopwatch { get; set; }

        public ActivityAction<TimeSpan> OnCompletion { get; set; }

        public Timer()

            Stopwatch = new Variable<Stopwatch>();

        protected override void CacheMetadata(NativeActivityMetadata metadata)

            metadata.AddImplementationVariable(Stopwatch);

            metadata.AddChild(Body);

            metadata.AddDelegate(OnCompletion);

        protected override void Execute(NativeActivityContext context)

            Stopwatch sw = new Stopwatch();

            Stopwatch.Set(context, sw);

            sw.Start();

            // schedule body and completion callback

            context.ScheduleActivity(Body, Completed);

        private void Completed(NativeActivityContext context, ActivityInstance instance)

            if (!context.IsCancellationRequested)

                Stopwatch sw = Stopwatch.Get(context);

                sw.Stop();

                Result.Set(context, sw.Elapsed);

                if (OnCompletion != null)

                    context.ScheduleAction<TimeSpan>(OnCompletion, Result.Get(context));

        protected override void Cancel(NativeActivityContext context)

            context.CancelChildren();

            if (OnCompletion != null)

                context.ScheduleAction<TimeSpan>(OnCompletion, TimeSpan.MinValue);

A few things to note about this code sample:

The declaration of an ActivityAction<TimeSpan> as a member of the activity. You’ll note we use the OnXXX convention often for activity actions.
The usage of the ActivityAction<T> with on type argument. The way to read this, or any of the 15 other types is that the T is the type of the data that will be passed to the activity action’s handler.
- Think about this like an Activity<Foo> corresponding to a void DoSomething(Foo argument1) method
The call to NativeActivityMetadata.AddDelegate() which lets the runtime know that it needs to worry about the delegate
The code in the Completed( ) method which checks to see if OnCompletion is set and then schedules it using ScheduleAction. I want to call out that line of code.

if (OnCompletion != null)
{
    context.ScheduleAction<TimeSpan>(OnCompletion, Result.Get(context));
}

It is important to note that I use the second parameter (and the third through 16th if that version is provided) in order to provide the data. This way, the activity determines what data will be passed to the handler, allowing the activity to determine what data is visible where. This is a much better way than allowing an invoked child to access any and all data from the parent. This lets us be very specific about what data goes to the ActivityAction. Also, you could make it so that OnCompletion must be provided, that is, the only way to use the activity is to supply an implementation. If you have something like “ProcessPayment” you likely want that to be a required thing. You can use the CacheMetadata method in order to check and validate this.

Now, let’s look at the code required to consume this time activity:

DelegateInArgument<TimeSpan> time = new DelegateInArgument<TimeSpan>();
a = new Timer
{
    Body = new HttpGet { Url = "http://www.microsoft.com" },
    OnCompletion = new ActivityAction<TimeSpan>
    {
        Argument = time,
        Handler = new WriteLine { 
            Text = new InArgument<string>(
                ctx => 
                    "Time input from timer " + time.Get(ctx).TotalMilliseconds)
        } 

    }
};

There are a couple of interesting things here:

Creation of DelegateInArgument<TimeSpan> : This is used to represent the data passed by the ActivityAction to the handler
Creation of the ActivityAction to pass in. You’ll note that the Argument property is set to the DelegateInArgument, which we can then use in the handler
The Handler is the “implementation” that we want to invoke. here’s it’s pretty simple, it’s a WriteLine and when we construct the argument we construct if from a lambda that uses the passed in context to resolve the DelegateInArgument when that executes.

At runtime, when we get to the point in the execution of the Timer activity, the WriteLine that the hosting app provided will be scheduled when the ScheduleAction is called. This means we will output the timing information that the Timer observed. A different implementation could have an IfThen activity and use that to determine if an SLA was enforced or not, and if not, send a nasty email to the WF author. The possibilities are endless, and they open up scenarios for you to provide specific extension points for your activities.

That wraps up a very brief tour of ActivityAction. ActivityAction provides a easy way to create an empty place in activity that the consumer can use to supply the logic that they want executed. In the second part of this post, we’ll dive into how to create a designer for one of these, how to represent this in XAML, and a few other interesting topics.

It’s that time of year that I’ll be taking a little bit of time off for the holidays, so I will see y’all in 2010!

Photo Credit

http://www.flickr.com/photos/myklroventine/ / CC BY 2.0

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

mwinkle — Wed, 23 Dec 2009 01:59:00 GMT

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="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://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

System.Activities.Presentation.Hosting.AssemblyContextControlItem

System.Activities.Presentation.Hosting.ReadOnlyState

System.Activities.Presentation.Hosting.WorkflowCommandExtensionItem

System.Activities.Presentation.View.Selection

System.Activities.Presentation.WorkflowFileItem

Services

System.Activities.Presentation.Debug.IDesignerDebugView

System.Activities.Presentation.DesignerPerfEventProvider

System.Activities.Presentation.FeatureManager

System.Activities.Presentation.Hosting.ICommandService

System.Activities.Presentation.Hosting.IMultiTargetingSupportService

System.Activities.Presentation.Hosting.WindowHelperService

System.Activities.Presentation.IActivityToolboxService

System.Activities.Presentation.IIntegratedHelpService

System.Activities.Presentation.IWorkflowDesignerStorageService

System.Activities.Presentation.IXamlLoadErrorService

System.Activities.Presentation.Model.AttachedPropertiesService

System.Activities.Presentation.Model.ModelTreeManager

System.Activities.Presentation.Services.ModelService

System.Activities.Presentation.Services.ViewService

System.Activities.Presentation.UndoEngine

System.Activities.Presentation.Validation.IValidationErrorService

System.Activities.Presentation.Validation.ValidationService

System.Activities.Presentation.View.ActivityTypeDesigner+DisplayNameUpdater

System.Activities.Presentation.View.DesignerView

System.Activities.Presentation.View.IExpressionEditorService

System.Activities.Presentation.View.ViewStateService

System.Activities.Presentation.View.VirtualizedContainerService

Basic Rehosted Application Standard Services and Items

Items

System.Activities.Presentation.Hosting.ReadOnlyState

System.Activities.Presentation.Hosting.WorkflowCommandExtensionItem

System.Activities.Presentation.View.Selection

Services

System.Activities.Presentation.DesignerPerfEventProvider

System.Activities.Presentation.FeatureManager

System.Activities.Presentation.Hosting.WindowHelperService

System.Activities.Presentation.Model.AttachedPropertiesService

System.Activities.Presentation.Model.ModelTreeManager

System.Activities.Presentation.Services.ModelService

System.Activities.Presentation.Services.ViewService

System.Activities.Presentation.UndoEngine

System.Activities.Presentation.Validation.ValidationService

System.Activities.Presentation.View.DesignerView

System.Activities.Presentation.View.ViewStateService

System.Activities.Presentation.View.VirtualizedContainerService

Comparison Table View

Items	VS	Rehosted
System.Activities.Presentation.Hosting.AssemblyContextControlItem	Yes	No
System.Activities.Presentation.Hosting.ReadOnlyState	Yes	Yes
System.Activities.Presentation.Hosting.WorkflowCommandExtensionItem	Yes	Yes
System.Activities.Presentation.View.Selection	Yes	Yes
System.Activities.Presentation.WorkflowFileItem	Yes	No

Services	VS	Rehosted
System.Activities.Presentation.Debug.IDesignerDebugView	Yes	No
System.Activities.Presentation.DesignerPerfEventProvider	Yes	Yes
System.Activities.Presentation.FeatureManager	Yes	Yes
System.Activities.Presentation.Hosting.ICommandService	Yes	No
System.Activities.Presentation.Hosting.IMultiTargetingSupportService	Yes	No
System.Activities.Presentation.Hosting.WindowHelperService	Yes	Yes
System.Activities.Presentation.IActivityToolboxService	Yes	No
System.Activities.Presentation.IIntegratedHelpService	Yes	No
System.Activities.Presentation.IWorkflowDesignerStorageService	Yes	No
System.Activities.Presentation.IXamlLoadErrorService	Yes	No
System.Activities.Presentation.Model.AttachedPropertiesService	Yes	Yes
System.Activities.Presentation.Model.ModelTreeManager	Yes	Yes
System.Activities.Presentation.Services.ModelService	Yes	Yes
System.Activities.Presentation.Services.ViewService	Yes	Yes
System.Activities.Presentation.UndoEngine	Yes	Yes
System.Activities.Presentation.Validation.IValidationErrorService	Yes	No
System.Activities.Presentation.Validation.ValidationService	Yes	Yes
System.Activities.Presentation.View.ActivityTypeDesigner+DisplayNameUpdater	Yes	No
System.Activities.Presentation.View.DesignerView	Yes	Yes
System.Activities.Presentation.View.IExpressionEditorService	Yes	No
System.Activities.Presentation.View.ViewStateService	Yes	Yes
System.Activities.Presentation.View.VirtualizedContainerService	Yes	Yes

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!

Emitting the mc:Ignorable Instruction In Your WF4 XAML

mwinkle — Thu, 10 Dec 2009 21:33:48 GMT

Frequent forum guest Notre posed this question to the forums the other day noting that the XAML being produced from ActivityXamlServices.CreateBuilderWriter() was slightly different than the XAML being output from WorkflowDesigner.Save(). The reason for this stems from the fact that WorkflowDesigner leverages an additional internal type (which derives from XamlXmlWriter) in order to attach the mc:Ignorable attribute.

Why use mc:Ignorable?

From the source at MSDN:

The mc XML namespace prefix is the recommended prefix convention to use when mapping the XAML compatibility namespace http://schemas.openxmlformats.org/markup-compatibility/2006.

Elements or attributes where the prefix portion of the element name are identified as mc:Ignorable will not raise errors when processed by a XAML processor. If that attribute could not be resolved to an underlying type or programming construct, then that element is ignored. Note however that ignored elements might still generate additional parsing errors for additional element requirements that are side effects of that element not being processed. For instance, a particular element content model might require exactly one child element, but if the specified child element was in an mc:Ignorable prefix, and the specified child element could not be resolved to a type, then the XAML processor might raise an error.

Basically, this lets a XAML reader gracefully ignore any content marked from that namespace if it cannot be resolved. So, imagine a runtime scenario where we don’t want to load System.Activities.Presentation every time we read a WF XAML file that may contain viewstate. As a result, we use mc:Ignorable, which means the reader will skip that content when it does not have that assembly referenced at runtime.

This is what the output from the designer usually contains:

<Sequence 
     mc:Ignorable="sap" 
     mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces"
     xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities" 
     xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
     xmlns:mva="clr-namespace:Microsoft.VisualBasic.Activities;assembly=System.Activities" 
     xmlns:sap="http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation" 
     xmlns:scg="clr-namespace:System.Collections.Generic;assembly=mscorlib" 
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <sap:WorkflowViewStateService.ViewState>
    <scg:Dictionary x:TypeArguments="x:String, x:Object">
      <x:Boolean x:Key="IsExpanded">True</x:Boolean>
    </scg:Dictionary>
  </sap:WorkflowViewStateService.ViewState>
  <Persist sap:VirtualizedContainerService.HintSize="211,22" />
  <Persist sap:VirtualizedContainerService.HintSize="211,22" />
  <WriteLine sap:VirtualizedContainerService.HintSize="211,61" />
</Sequence>

mc:Ignorable will cause the ViewState and HintSize to be ignored.

Why do I have to worry about this?

If you use WorkflowDesigner.Save(), you don’t. If you want to be able to serialize the ActivityBuilder and have XAML which is what the designer produces, you need will need to add a XamlXmlWriter into the XamlWriter stack in order to get the right output. You may also worry about this if you are implementing your own storage and plan on writing some additional XAML readers or writers for additional extensibility and flexibility.

How Do I Get the Same Behavior?

The code below describes the same approach you would need to take to implement an XamlXmlWriter that does the same thing our internal type does. While I can’t copy and paste code, this does the same thing. We do two things:

Override WriteNamespace() to collect all of the namespaces being emitted. We do this to specifically check for ones that we should ignore, and to also gather all of the prefixes to make sure we don’t have a collision
Override WriteStartObject() to generate and write out the Ignorable attribute within the start (first) member for any namespaces we should ignore.

What namespaces do we ignore in the designer? Just one: http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation

using System.Collections.Generic;

using System.IO;

using System.Xaml;

using System.Xml;

namespace IgnorableXamlWriter

    class IgnorableXamlXmlWriter : XamlXmlWriter

        HashSet<NamespaceDeclaration> ignorableNamespaces = new HashSet<NamespaceDeclaration>();

        HashSet<NamespaceDeclaration> allNamespaces = new HashSet<NamespaceDeclaration>();

        bool objectWritten;

        bool hasDesignNamespace;

        string designNamespacePrefix;

        public IgnorableXamlXmlWriter(TextWriter tw, XamlSchemaContext context)

            : base(XmlWriter.Create(tw,

                                    new XmlWriterSettings { Indent = true, OmitXmlDeclaration = true }),

                                    context,

                                    new XamlXmlWriterSettings { AssumeValidInput = true })

        public override void WriteNamespace(NamespaceDeclaration namespaceDeclaration)

            if (!objectWritten)

                allNamespaces.Add(namespaceDeclaration);

                // if we find one, add that to ignorable namespaces

                // the goal here is to collect all of them that might point to this

                // if you had a broader set of things to ignore, you would collect

                // those here.

                if (namespaceDeclaration.Namespace == "http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation")

                    hasDesignNamespace = true;

                    designNamespacePrefix = namespaceDeclaration.Prefix;

            base.WriteNamespace(namespaceDeclaration);

        public override void WriteStartObject(XamlType type)

            if (!objectWritten)

                // we should check if we should ignore

                if (hasDesignNamespace)

                    // note this is not robust as mc could naturally occur

                    string mcAlias = "mc";

                    this.WriteNamespace(

                        new NamespaceDeclaration(

                            "http://schemas.openxmlformats.org/markup-compatibility/2006",

                            mcAlias)

);

            base.WriteStartObject(type);

            if (!objectWritten)

                if (hasDesignNamespace)

                    XamlDirective ig = new XamlDirective(

                        "http://schemas.openxmlformats.org/markup-compatibility/2006",

                        "Ignorable");

                    WriteStartMember(ig);

                    WriteValue(designNamespacePrefix);

                    WriteEndMember();

                    objectWritten = true;

One note on the code above, it is noted that the generation of the namespace prefix “mc” is not robust. In the product code we will check to see if mc1, mc2, … are available up to mc1000. In that case we would then append a GUID for the ugliest XML namespace known to mankind. The chance of collision up to 1000 would be a highly extreme edge case.

How would I use this? The following code shows feeding this into a CreateBuilderWriter that is passed to XamlServices.Save()

StringBuilder sb = new StringBuilder();
XamlSchemaContext xsc = new XamlSchemaContext();
var bw = ActivityXamlServices.CreateBuilderWriter(
    new IgnorableXamlXmlWriter(new StringWriter(sb), xsc));

XamlServices.Save(bw,
                  wd.Context.Services.GetService<ModelTreeManager>().Root.GetCurrentValue());

AttachedProperty Part 2, Putting it Together

mwinkle — Mon, 07 Dec 2009 05:19:09 GMT

On my last post , Jason jumped right to the punchline in his comment here . He asks “if there is an easy way to have the properties value serialized out to the xaml.”

First, let’s look at what we need to do from the XAML side.

First, create a helper type with a getter and setter for the property that you want to attach. Here we’re going to attach comments:

public class Comment
{
    static AttachableMemberIdentifier CommentTextName = new AttachableMemberIdentifier(typeof(Comment), "CommentText");

    public static object GetCommentText(object instance)
    {
        object viewState;
        AttachablePropertyServices.TryGetProperty(instance, CommentTextName, out viewState);
        return viewState;
    }

    public static void SetCommentText(object instance, object value)
    {
        AttachablePropertyServices.SetProperty(instance, CommentTextName, value);
    }

}

Next, let’s use the AttachableMemberIdentifier and the AttachablePropertyServices to do something interesting with this:

AttachableMemberIdentifier ami = new AttachableMemberIdentifier(typeof(Comment), "CommentText");
Dog newDog = new Dog { Age = 12, Name = "Sherlock", Noise = "Hooowl" };
AttachablePropertyServices.SetProperty(newDog, ami, "A very good dog");
string s = XamlServices.Save(newDog);
Console.WriteLine("XAML");
Console.WriteLine(s);
Dog aSecondNewDog = XamlServices.Load(new StringReader(s)) as Dog;
string outter;
AttachablePropertyServices.TryGetProperty(aSecondNewDog, ami, out outter);
Console.WriteLine("read out: {0}", outter);

Let’s see the output from this:

XAML
<Dog
     Age="12"
     Comment.CommentText="A very good dog"
     Name="Sherlock"
     Noise="Hooowl" 
     xmlns="clr-namespace:AttachedPropertiesBlogPosting;assembly=AttachedPropertiesBlogPosting" />
read out: A very good dog

You’ll note that the value is contained in the XAML under Comment.CommentText.

Pulling it all Together

Let’s take what we did in the last post and combine it with the above stuff in order to have an attached property that writes through and is stored inside the XAML.

AttachedProperty<string> Comment = new AttachedProperty<string>
{
    IsBrowsable = true,
    Name = "Comment",
    Getter = (mi =>
        { string temp;
          AttachablePropertyServices.TryGetProperty<string>(mi.GetCurrentValue(), ami, out temp);
          return temp;
        }),
    Setter = ( (mi,val) => AttachablePropertyServices.SetProperty(mi.GetCurrentValue(), ami, val) )

};
aps.AddProperty(Comment);
dogMi.Properties["Comment"].SetValue("I think I like that dog");
string xaml = XamlServices.Save(dogMi.GetCurrentValue());
Console.WriteLine("XAML");
Console.WriteLine(xaml);

What are we doing here, well, we basically just use the Getter and Setter to write through to the underlying instance. You’ll note that usually, we never want to go and use GetCurrentValue(), as any changes made there are not made via the ModelItem tree which means we might miss a change notification. However, given that the only place where we can store the XAML attached property is on the instance itself, this gives us a good way to write through. The XAML output below shows that this works as expected:

<Dog 
   Age="5"
   Comment.CommentText="I think I like that dog"
   Name="Sasha" 
   Noise="Snort" 
   xmlns="clr-namespace:AttachedPropertiesBlogPosting;assembly=AttachedPropertiesBlogPosting" />

WF4 Design Time AttachedPropertiesService and Attached Properties

mwinkle — Sun, 06 Dec 2009 04:51:01 GMT

I’ve been meaning to throw together some thoughts on attached properties and how they can be used within the designer. Basically, you can think about attached properties as injecting some additional “stuff” onto an instance that you can use elsewhere in your code.

Motivation

In the designer, we want to be able to have behavior and view tied to interesting aspects of the data. For instance, we would like to have a view updated when an item becomes selected. In WPF, we bind the style based on the “isSelectionProperty.” Now, our data model doesn’t have any idea of selection, it’s something we’d like the view level to “inject” that idea on any model item so that a subsequent view could take advantage of. You can kind of view Attached Properties as a nice syntactic sugar to not have to keep a bunch of lookup lists around. As things like WPF bind to the object very well, and not so much a lookup list, this ends up being an interesting model.

To be clear, you could write a number of value converters that take the item being bound, look up in a lookup list somewhere, and return the result that will be used. The problem we found is that we were doing this in a bunch of places, and we really wanted to have clean binding statements inside our WPF XAML, rather than hiding a bunch of logic in the converters.

How Does it Work

First, some types.

Name	Description
AttachedPropertiesService	Service in editing context for managing AttachedProperties
AttachedProperty	Base attached property type (abstract)
AttachedProperty<T>	Strongly typed attached property with interesting getter/setter programmability

in diagram form:

One thing that might look a little funny to some folks who have used attached properties in other contexts (WF3, WPF, XAML), is the “IsBrowsable ” property. The documentation is a little sparse right now, but what this will do is determine how discoverable the property is. If this is set to true, the attached property will show up in the Properties collection of the ModelItem to which the AP is attached. What this means is that it can show up in the Property grid, you can bind WPF statements directly to it, as if it were a real property of the object. Attached properties by themselves have no actual storage representation, so these exist as design time only constructs.

Getter/ Setter?

One other thing that you see on the AttachedProperty<T> is the Getter and Setter properties. These are of type Func<ModelItem,T> and Action<ModelItem,T> respectively. What these allow you to do is perform some type of computation whenever the get or set is called against the AttachedProperty. Why is this interesting? Well, let’s say that you’d like to have a computed value retrieved, such as “IsPrimarySelection” checking with the Selection context item to see if an item is selected. Or, customizing the setter to either store the value somewhere more durable, or updating a few different values. The other thing that happens is that since all of these updates go through the ModelItem tree, any changes will be propagated to other listeners throughout the designer.

Looking at Some Code

Here is a very small console based app that shows how you can program against the attached properties. An interesting exercise for the reader would be to take this data structure, put it in a WPF app and experiment with some of the data binding.

First, two types:

public class Dog
{
    public string Name { get; set; }
    public string Noise { get; set; }
    public int Age { get; set; }
   
}

public class Cat
{
    public string Name { get; set; }
    public string Noise { get; set; }
    public int Age { get; set; }
}

Ignore no common base type, that actually makes this a little more interesting, as we will see.

Now, let’s write some code. First, let’s initialize and EditingContext and ModelTreeManager.

   1:       static void Main(string[] args)

   2:          {

   3:              EditingContext ec = new EditingContext();

   4:              ModelTreeManager mtm = new ModelTreeManager(ec);

   5:              mtm.Load(new object[] { new Dog { Name = "Sasha", Noise = "Snort", Age = 5 },

   6:                                      new Cat { Name="higgs", Noise="boom", Age=1 } });

   7:              dynamic root = mtm.Root;

   8:              dynamic dog = root[0];

   9:              dynamic cat = root[1];

  10:              ModelItem dogMi = root[0] as ModelItem;

  11:              ModelItem catMi = root[1] as ModelItem;

Note, lines 7-9 will not work in Beta2 (preview of coming attractions). To get lines 10-11 working in beta2, cast root to ModelItemCollection and then use the indexers to extract the values

Now, let’s build an attached property, and we will assign it only to type “dog”

   1:  // Add an attached Property

   2:  AttachedProperty<bool> ap = new AttachedProperty<bool>

   3:  {

   4:      IsBrowsable = true,

   5:      Name = "IsAnInterestingDog",

   6:      Getter = (mi => mi.Properties["Name"].ComputedValue.ToString() == "Sasha"),

   7:      OwnerType = typeof(Dog)

   8:  };

   9:  ec.Services.Publish<AttachedPropertiesService>(new AttachedPropertiesService());

  10:  AttachedPropertiesService aps = ec.Services.GetService<AttachedPropertiesService>();

  11:  aps.AddProperty(ap);

12:

  13:  Console.WriteLine("---- Enumerate properties on dog (note new property)----");

  14:  dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

15:

  16:  Console.WriteLine("---- Enumerate properties on cat (note  no new property) ----");

  17:  catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

Let’s break down what happened here.

Line2-8, create an AttachedProperty<bool>

We set IsBrowsable to true, we want to see it in the output
Name, that’s what it will be projected as
OwnerType, we only want this to apply to Dog’s, not Cat’s or Objects or whatever.
Finally, Getter, and look what we do here, we operate on the model item to do some computation and return a bool (in this case, we look to see if the name property equals “Sasha”

Line 9-11 create an AttachedPropertiesService and add it to the editing context.
Lines 13-17 output the properties, and let’s see what that looks like:

---- Enumerate properties on dog (note new property)----

 Property : Name

 Property : Noise

 Property : Age

 Property : IsAnInterestingDog

---- Enumerate properties on cat (note  no new property) ----

 Property : Name

 Property : Noise

 Property : Age

Ok, so that’s interesting, we’ve injected a new property, only on the dog type. If I got dogMI.Properties[“IsAnInterestingDog”], I would have a value that I could manipulate (albeit returned via the getter).

Let’s try something a little different:

   1:  AttachedProperty<bool> isYoungAnimal = new AttachedProperty<bool>

   2:  {

   3:      IsBrowsable = false,

   4:      Name = "IsYoungAnimal",

   5:      Getter = (mi => int.Parse(mi.Properties["Age"].ComputedValue.ToString()) < 2)

   6:  };

7:

   8:  aps.AddProperty(isYoungAnimal);

9:

  10:  // expect to not see isYoungAnimal show up

  11:  Console.WriteLine("---- Enumerate properties on dog  (note isYoungAnimal doesn't appear )----");

  12:  dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

  13:  Console.WriteLine("---- Enumerate properties on cat (note isYoungAnimal doesn't appear )----");

  14:  catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

15:

  16:  Console.WriteLine("---- get attached property via GetValue ----");

  17:  Console.WriteLine("getting non browsable attached property on dog {0}", isYoungAnimal.GetValue(dogMi));

  18:  Console.WriteLine("getting non browsable attached property on cat {0}", isYoungAnimal.GetValue(catMi));

Let’s break this down:

Lines 1-6 create a new attached property

IsBrowsable is false
No OwnerType being set
The Getter does some computation to return true or false

Lines 10-14 write out the properties (as above)
Lines 17-18 extract the value with AttachedPropertyInstance.GetValue(ModelItem)

Let’s see the output there:

---- Enumerate properties on dog  (note isYoungAnimal doesn't appear )----

 Property : Name

 Property : Noise

 Property : Age

 Property : IsAnInterestingDog

---- Enumerate properties on cat (note isYoungAnimal doesn't appear )----

 Property : Name

 Property : Noise

 Property : Age

---- get attached property via GetValue ----

getting non browsable attached property on dog False

getting non browsable attached property on cat True

As we can see, we’ve now injected this behavior, and we can extract the value.

Let’s get a little more advanced and do something with the setter. Here, if isYoungAnimal is set to true, we will change the age (it’s a bit contrived, but shows the dataflow on simple objects, we’ll see in a minute a more interesting case).

   1:  // now, let's do something clever with the setter.

   2:  Console.WriteLine("---- let's use the setter to have some side effect ----");

   3:  isYoungAnimal.Setter = ((mi, val) => { if (val) { mi.Properties["Age"].SetValue(10); } });

   4:  isYoungAnimal.SetValue(cat, true);

   5:  Console.WriteLine("cat's age now {0}", cat.Age);

Pay attention to what the Setter does now. We create the method through which subsequent SetValue’s will be pushed. Here’s that output:

---- let's use the setter to have some side effect ----
cat's age now 10

Finally, let’s show an example of how this can really function as some nice sugar to eliminate the need for a lot of value converters in WPF by using this capability as a way to store the relationship somewhere (rather than just using at a nice proxy to change a value):

   1:  // now, let's have a browesable one with a setter.

   2:  // this plus dynamics are a mini "macro language" against the model items

3:

   4:  List<Object> FavoriteAnimals = new List<object>();

5:

   6:  // we maintain state in FavoriteAnimals, and use the getter/setter func

   7:  // in order to query or edit that collection.  Thus changes to an "instance"

   8:  // are tracked elsewhere.

   9:  AttachedProperty<bool> isFavoriteAnimal = new AttachedProperty<bool>

  10:  {

  11:      IsBrowsable = false,

  12:      Name = "IsFavoriteAnimal",

  13:      Getter = (mi => FavoriteAnimals.Contains(mi)),

  14:      Setter = ((mi, val) =>

  15:          {

  16:              if (val)

  17:                  FavoriteAnimals.Add(mi);

  18:              else

  19:              {

  20:                  FavoriteAnimals.Remove(mi);

  21:              }

  22:          })

  23:  };

24:

25:

  26:  aps.AddProperty(isFavoriteAnimal);

27:

  28:  dog.IsFavoriteAnimal = true;

  29:  // remove that cat that isn't there

  30:  cat.IsFavoriteAnimal = false;

  31:  cat.IsFavoriteAnimal = true;

  32:  cat.IsFavoriteAnimal = false;

33:

  34:  Console.WriteLine("Who are my favorite animal?");

  35:  FavoriteAnimals.ForEach(o => Console.WriteLine((o as ModelItem).Properties["Name"].ComputedValue.ToString()));

Little bit of code, let’s break it down one last time:

Line 14 – Create a setter that acts upon the FavoriteAnimals collection to either add or remove the element
Line 28-32 – do a few different sets on this attached property

NOTE: you can’t do that in beta2 as the dynamic support hasn’t been turned on. Rather you would have to do isFavoriteAnimal.SetValue(dogMi, true).

Line 35 then prints the output to the console, and as expected we only see the dog there:

-- Who are my favorite animals?
Sasha

I will attach the whole code file at the bottom of this post, but this shows you how you can use the following:

Attached properties to create “computed values” on top of existing types
Attached properties to inject a new (and discoverable) property entry on top of the designer data model (in the form of a new property)
Using the Setter capability to both propagate real changes to the type, providing a nice way to give a cleaner interface, as well as use it as a mechanism to store data about the object outside of the object, but in a way that gives me access to it such that it seems like the object.

This is some really nice syntactic sugar that we sprinkle on top of things

What do I do now?

Hopefully this post gave you some ideas about how the attached property mechanisms work within the WF4 designer. These give you a nice way to complement the data model and create nice bindable targets that your WPF Views can layer right on top of.

A few ideas for these things:

Use the Setters to clean up a “messy” activity API into a single property type that you then build a custom editor for in the property grid.
Use the Getters (and the integration into the ModelProperty collection) in order to create computational properties that are used for displaying interesting information on the designer surface.
Figure out how to bridge the gap to take advantage of the XAML attached property storage mechanism, especially if you author runtime types that look for attached properties at runtime.
Use these, with a combination of custom activity designers to extract and display interesting runtime data from a tracking store

Full Code Posting

using System;
using System.Activities.Presentation;
using System.Activities.Presentation.Model;
using System.Collections.Generic;
using System.Linq;

namespace AttachedPropertiesBlogPosting
{
    class Program
    {
        static void Main(string[] args)
        {
            EditingContext ec = new EditingContext();
            ModelTreeManager mtm = new ModelTreeManager(ec);
            mtm.Load(new object[] { new Dog { Name = "Sasha", Noise = "Snort", Age = 5 },
                                    new Cat { Name="higgs", Noise="boom", Age=1 } });
            dynamic root = mtm.Root;
            dynamic dog = root[0];
            dynamic cat = root[1];
            ModelItem dogMi = root[0] as ModelItem;
            ModelItem catMi = root[1] as ModelItem;
          
            // Add an attached Property
            AttachedProperty<bool> ap = new AttachedProperty<bool>
            {
                IsBrowsable = true,
                Name = "IsAnInterestingDog",
                Getter = (mi => mi.Properties["Name"].ComputedValue.ToString() == "Sasha"),
                OwnerType = typeof(Dog)
            };
            ec.Services.Publish<AttachedPropertiesService>(new AttachedPropertiesService());
            AttachedPropertiesService aps = ec.Services.GetService<AttachedPropertiesService>();
            aps.AddProperty(ap);

            Console.WriteLine("---- Enumerate properties on dog (note new property)----");
            dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

            Console.WriteLine("---- Enumerate properties on cat (note  no new property) ----");
            catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));


            
            AttachedProperty<bool> isYoungAnimal = new AttachedProperty<bool>
            {
                IsBrowsable = false,
                Name = "IsYoungAnimal",
                Getter = (mi => int.Parse(mi.Properties["Age"].ComputedValue.ToString()) < 2)
            };

            aps.AddProperty(isYoungAnimal);

            // expect to not see isYoungAnimal show up
            Console.WriteLine("---- Enumerate properties on dog  (note isYoungAnimal doesn't appear )----");
            dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));
            Console.WriteLine("---- Enumerate properties on cat (note isYoungAnimal doesn't appear )----");
            catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

            Console.WriteLine("---- get attached property via GetValue ----");
            Console.WriteLine("getting non browsable attached property on dog {0}", isYoungAnimal.GetValue(dogMi));
            Console.WriteLine("getting non browsable attached property on cat {0}", isYoungAnimal.GetValue(catMi));
            
            
            // now, let's do something clever with the setter. 
            Console.WriteLine("---- let's use the setter to have some side effect ----");
            isYoungAnimal.Setter = ((mi, val) => { if (val) { mi.Properties["Age"].SetValue(10); } });
            isYoungAnimal.SetValue(cat, true);
            Console.WriteLine("cat's age now {0}", cat.Age);

            // now, let's have a browesable one with a setter.
            // this plus dynamics are a mini "macro language" against the model items

            List<Object> FavoriteAnimals = new List<object>();

            // we maintain state in FavoriteAnimals, and use the getter/setter func
            // in order to query or edit that collection.  Thus changes to an "instance"
            // are tracked elsewhere.
            AttachedProperty<bool> isFavoriteAnimal = new AttachedProperty<bool>
            {
                IsBrowsable = false,
                Name = "IsFavoriteAnimal",
                Getter = (mi => FavoriteAnimals.Contains(mi)),
                Setter = ((mi, val) => 
                    {
                        if (val)
                            FavoriteAnimals.Add(mi);
                        else
                        {
                            FavoriteAnimals.Remove(mi);
                        }
                    })
            };
            aps.AddProperty(isFavoriteAnimal);
            dog.IsFavoriteAnimal = true;
            // remove that cat that isn't there
            cat.IsFavoriteAnimal = false;
            cat.IsFavoriteAnimal = true;
            cat.IsFavoriteAnimal = false;
            Console.WriteLine("Who are my favorite animals?");
            FavoriteAnimals.ForEach(o => Console.WriteLine((o as ModelItem).Properties["Name"].ComputedValue.ToString()));
            Console.ReadLine();
        }
    }

    public class Dog
    {
        public string Name { get; set; }
        public string Noise { get; set; }
        public int Age { get; set; }
    }

    public class Cat
    {
        public string Name { get; set; }
        public string Noise { get; set; }
        public int Age { get; set; }
    }
}

WF4 ViewStateService

mwinkle — Sun, 06 Dec 2009 01:33:20 GMT

A comment posted by Notre asked for some more details about view state and attached property services, so I thought I would dive into those next. I will follow-up in a subsequent post on the AttachedPropertyService, as there is a little bit more going on there.

Motivation

Why do I care about viewstate? Well, usually it is because we want to write something down and store it for later that is not required for runtime. A common example of viewstate is the position of nodes within a flowchart. While not required to execute the flowchart, they are required to effectively view the flowchart.

Where to write them down?

This was a question that caused a fair amount of debate on the team. There are basically two places to write down things like view state in a file-based world.

In the source document itself
In a document that stays close to the source (usually referred to as a sidecar file)

We had customers asking for both. The motivation for the first is that for things like flowchart, where I may always care about the visualization representation, I want to keep that metadata around and only deal with one element. For the second, it is motivated by the reason that we want a clean source document that only describes the minimal artifact to run. Now, there are certainly many stops along the spectrum (for instance, we might always want to keep annotations or source comments in the source document, and put positioning elsewhere). For VS2010, we landed with a unified API to use, and we write in the source document. This is something that is likely to change in future releases, as it does make things like textual diffs rather painful.

So, that’s why we want to use it.

How do we use it?

We are going to create a simple activity designer that lets me write down a comment.

A few simple steps:

Create a new VS Project, let’s create an Activity Library
Add a Designer to that activity library
Add an attribute to the activity pointing to the designer
Add a new WorkflowConsoleApp Project
Build

Now, let’s go and make our activity designer a little interesting.

Let’s add a text box and a button. We’ll make the text of the button something obvious like “commit comment” The XAML for the activity designer looks like this:

<sap:ActivityDesigner x:Class="simpleActivity.CommentingDesigner"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://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>
        <StackPanel Name="stackPanel1" VerticalAlignment="Top" >
            <TextBox  Name="commentBlock"   />
            <Button Content="Load View State" Name="loadViewState" Click="loadViewState_Click" />
            <Button Content="Commit View State"  Name="button1" Click="button1_Click" />
        </StackPanel>
    </Grid>
</sap:ActivityDesigner>

Now, let’s add some code to the button (and to the initialization of the form)

ViewStateService has a few useful methods on it. I want to call out a subtle difference. You will see StoreViewState and StoreViewStateWithUndo. The primary distinction as the name implies is that one will simply write the view state down and will bypass the undo/redo stack. This is for view state like an expanded/collapsed view. You don’t really want ctl-z to simply flip expanded versus collapsed for you. But for something like flowchart, where changing some of the viewstate, like position, might be such a thing that you want support for undoing the action. That’s the primary difference.

So, our code for the button looks like this:

private void button1_Click(object sender, RoutedEventArgs e)
{
    ViewStateService vss = this.Context.Services.GetService<ViewStateService>();
    vss.StoreViewStateWithUndo(this.ModelItem, "comment", commentBlock.Text);
}

Now, on load, we want to be able to populate the value, so we will use the RetrieveViewState method in order to extract this.

private void loadViewState_Click(object sender, RoutedEventArgs e)
{
    ViewStateService vss = this.Context.Services.GetService<ViewStateService>();
    commentBlock.Text = vss.RetrieveViewState(this.ModelItem, "comment") as string;
}

Now, let’s go back to our workflow project and put an instance of this activity on the surface:

Let’s add some viewstate information and commit it. Now let’s look at the XAML:

<s4:NotRealInterestingActivity Text="{x:Null}" sap:VirtualizedContainerService.HintSize="200,99">
  <sap:WorkflowViewStateService.ViewState>
    <scg3:Dictionary x:TypeArguments="x:String, x:Object">
      <x:String x:Key="comment">basic comment</x:String>
    </scg3:Dictionary>
  </sap:WorkflowViewStateService.ViewState>
</s4:NotRealInterestingActivity>

Ok, now, to show that we can pull this in, let’s change the text in the xaml and then reload our designer.

You can muck around with ctl-z to see that this does get handled correctly via the undo.

The other important thing to note is that this takes an object, so your viewstate is not limited to strings, you can have more full featured objects if you’d like. Finally, the ViewStateService also has a ViewStateChanged you can subscribe to in order to handle, dispatch, and react to view state changes in the designer.

Where is System.Activities.Design in WF4 Beta2 and Beyond?

mwinkle — Sat, 05 Dec 2009 23:40:33 GMT

I got an email over the weekend asking about this, and I realized that it’s somewhat buried in this post here. Anyway, in Beta1, you often saw System.Activities.Design. For beta2 (and RTM), one important change

System.Activities.Design => System.Activities.Presentation

The primary reason for this change is that the *.Design suffix is generally reserved for VS design extensibility. As our designer ships in the framework, *.Design was not the correct suffix. *.Presentation is where we landed.

Hoping that putting this in the title lands this high up in search queries so that this post might be useful for a few people.

WF4, WCF and AppFabric Sessions @ PDC09

mwinkle — Mon, 23 Nov 2009 23:16:44 GMT

I’m taking this week off to catch up on everything I haven’t done the last two months and to celebrate the Thanksgiving holiday here in the US.

PDC was a blast! It was incredibly awesome to meet so many folks interested in WF and talking with others about how they are using (or plan to use) WF4. I’ll be following up with a more detailed post on my talk, including demos and code, but I wanted to give a summary of the talks that came from my team at this PDC. Below is the diagram that breaks down some of the “capabilities” of AppFabric and I have color coded them for the various talks that we gave. All of the PDC Sessions are available online here.

WF Talks

Spice Up Your Applications with Windows Workflow Foundation 4 – Matt Winkler
Windows Workflow Foundation 4 from the Inside Out – Bob Schmidt

WCF Talks

What’s New for Windows Communication Foundation 4 – Ed Pinto
Developing REST Applications with the .NET Framework – Henrik Nielsen

AppFabric Talks

Microsoft Application Server Technologies: Present and Future – Anil Nori
Microsoft BizTalk Server Futures and Roadmap – Balasubramanian Sriram
Workflow Services and Windows Server AppFabric – Mark Fussell
Application Server Extensibility with Microsoft .NET 4 and Windows Server AppFabric – Nicholas Allen

There’s a ton of great content up at the PDC site, plenty to sit back and enjoy!

Finding the Variables in Scope Within the WF Designer

mwinkle — Fri, 06 Nov 2009 06:21:35 GMT

In this thread, one of our forum customers asked the question:

“how do I find all of the variables that are in scope for a given activity in the designer?”

We do not have a public API to do this. Internally we have a helper type called VariableHelper that we use to display the list of variables in the variable designer, as well as passed into the expression text box intellisense control.

One thing that I would like to point out is that if you are implementing your expression editor and want to be able to enumerate the variables (to highlight the tokens that are in scope), your implementation of IExpressionEditorService.CreateExpressionEditor() will get a list of model items that correspond to the inscope variables.

Now, if you are not building an expression editor, and want to be able to enumerate all of the in scope variables, you will need to do a little more work. Here are the basic steps

Go to parent container
Does it contain variables*
Does it have a parent?
Go to parent’s parent
Repeat from step 2

* This is basically the tricky part, because it is not something we can cleanly determine (and it can also be altered at runtime by adding some additional ones via the CacheMetadata() method. I’ll describe what the designer is currently doing to accumulate this list, and then talk about designs we could have in a future release.

Current Approach

Currently, there are two things that we look for when we navigate up the model item tree.

Collections of Variables name Variables
Variables injected by the use of ActivityAction

As we walk up the tree, we need to find these. Let’s first consider the following workflow we will use for our tests:

   1:  wd.Load(new Sequence

   2:  {

   3:      Activities =

   4:      {

   5:          new Sequence

   6:          {

   7:              Activities =

   8:              {

   9:                  new ForEach<string>

  10:                  {

  11:                      Body = new ActivityAction<string>

  12:                      {

  13:                           Argument = new DelegateInArgument<string> { Name="foo" },

  14:                           Handler =

  15:                              new Sequence

  16:                              {

  17:                                  Activities =

  18:                                  {

  19:                                      new WriteLine()

  20:                                  }

  21:                              }

  22:                      }

  23:                  }

  24:              }

  25:          }

  26:      }

  27:  });

Line 13 is the only one that might look a little different here, I’ll eventually have a post up about ActivityAction that talks in more detail what’s going on there.

So, this loaded in a rehosted designer looks like the following:

Now, let’s look at the code to figure out what is in scope of the selected element. First, let’s get the selected element :-)

 Selection  sel = wd.Context.Items.GetValue<Selection>();
 if (sel != null)
 {
        ModelItem mi = sel.PrimarySelection;

mi is now the model item of my selected item. Let’s write some code to walk up the tree and add to a collection called variables

   1:  while (mi.Parent != null)

   2:  {

   3:      Type parentType = mi.Parent.ItemType;

   4:      if (typeof(Activity).IsAssignableFrom(parentType))

   5:      {

   6:          // we have encountered an activity derived type

   7:          // look for variable collection

   8:          ModelProperty mp = mi.Parent.Properties["Variables"];

   9:          if (null != mp && mp.PropertyType == typeof(Collection<Variable>))

  10:          {

  11:              mp.Collection.ToList().ForEach(item => variables.Add(item));

  12:          }

  13:      }

  14:      // now we need to look action handlers

  15:      // this will ideally return a bunch of DelegateArguments

  16:      var dels = mi.Properties.Where(p => typeof(ActivityDelegate).IsAssignableFrom(p.PropertyType));

  17:      foreach (var actdel in dels)

  18:      {

  19:          if (actdel.Value != null)

  20:          {

  21:              foreach (var innerProp in actdel.Value.Properties)

  22:              {

  23:                  if (typeof(DelegateArgument).IsAssignableFrom(innerProp.PropertyType) && null != innerProp.Value)

  24:                  {

  25:                      variables.Add(innerProp.Value);

  26:                  }

  27:              }

  28:          }

  29:      }

30:

31:

  32:      mi = mi.Parent;

  33:  }

Lines 4-13 handle the case where I just encounter an activity. Lines 16-29 handle the slightly more tricky case where I need to handle ActivityAction (which ultimately derives from ActivityDelegate). There are a few loops there but basically I look through all of the properties of the item which inherit from ActivityDelegate. For each one of those, and for each property on that, I look for properties assignable from DelegateArgument. As I find them I add them to my collection of model items for variables.

In my WPF app, I have a simple list box that shows all of these. Because of the loosely typed data template I use in my WPF app, I get a pretty decent display since they share common things like ItemType from ModelItem, and a Name that routes through to the underlying Name property both elements share.

<ListBox Name="listBox1" Grid.Row="1" Grid.ColumnSpan="2" Grid.Column="0">

    <ListBox.ItemTemplate>

        <DataTemplate>

            <StackPanel Orientation="Horizontal">

                <TextBlock>Foo:</TextBlock>

                <TextBlock FontWeight="Bold" Text="{Binding Path=ItemType}"/>

                <TextBlock Text="{Binding Path=Name}"/>

            </StackPanel>

        </DataTemplate>

    </ListBox.ItemTemplate>

</ListBox>

Potential Future Approach

Our approach outlined above is generally correct. That said, you can imagine a deeply nested data structure on an activity that contain variables that get injected into the scope at runtime. We need a way for an activity to provide a way to declare how to get all of its variables. The current approach is one of inspection, which works for all of our activities. In the future we may need to add an extensibility point to allow an activity author to specify how to find the variables that are available to its children. The way that we could do that is to introduce an “VariableResolver” attribute which points to a type (or maybe a Func<>) that operates on the activity and returns the list of variables. Actually today you could likely introduce a custom type descriptor that lifted the variables out of the activity and surfaces them in such a way that they would be discovered by the inspection above.

Disclaimer: the Potential Future Approach is simply something that we’ve discussed that we could do, it does not represent something that we will do. If you think that is an interesting extensibility point that you might want to take advantage of down the road, let me know.

WF4 Beta1 => Beta2 Breaking Changes Document Published

mwinkle — Mon, 02 Nov 2009 05:24:44 GMT

Fresh on microsoft.com downloads, you can get the details of the major breaking changes that occurred for WF between Beta 1 and Beta 2.

Get the document here.

We will publish a similar document for any changes between Beta2 and RTM, although that list should be on the shorter side. If you have feedback on the document, like the way something is presented or think we could have done a better job explaining it, please let me know. Either comment here or use the “Email” link on the side.

WF4 Designer Bloggers

mwinkle — Wed, 28 Oct 2009 17:29:52 GMT

I wanted to put a quick note up as the team is starting to blog a little more frequently and putting some interesting content out there. A few places to check out to hear from the folks on the team

Endpoint – This is the general WF team blog, and has had some good posts

Cathy Dumas – Cathy is the PM on my team focused on the expression editing experience and the designer UX

Kushal Shah – Kushal is the PM on my team for debugging and Visual Studio integration

What blogs are you reading for WF4 content? What kind of stuff would you like to hear more about? Let us know!

Types, Metatypes and Bears, Redux

mwinkle — Fri, 23 Oct 2009 16:16:29 GMT

I made a quick post a few months back where I tried to talk about the way the designer works and lets us design types, as well as simply configure instances of types.

There were a couple of key points that I wanted to make there in that post:

The workflow designer can configure instances of activity graphs, and create entire types as well
Types are designed by editing an instance of a type that represents the type being designed, the metatype
There is some XAML trickery required to serialize and deserialize this
This same type of work is done to enable the DynamicActivity capability

A few folks have noticed (and sent me mail), that things look a little different in Beta2. While we are going to have a more thorough, “here’s everything that changed” doc, I want to go ahead and update at least some of the things that I’ve been talking about here.

What’s New

In reality, very little is new, we’ve primarily moved stuff around now. One thing that you may remember is that the DesignTimeXamlReader was not public in beta1, and if you are looking around, you may not find it. We have made this functionality public however. Thus, see the “what’s changed" bit.

What’s Changed

We took a long look at things and realized we had a bunch of XAML stuff all over the place. We felt it would be a good idea to try to consolidate that into one place in WF, so System.Activities.XamlIntegration.ActivityXamlServices becomes your one stop shop for most things Activity and XAML related. Let’s take a quick look and see what’s in there:

ActivityXamlServices Members

[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]

Creates an instance of an activity tree described in XAML.

The ActivityXamlServices type exposes the following members.

Methods

Name

Description

CreateBuilderReader

Overloaded. Maps an x:Class activity tree to an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>).

CreateBuilderWriter

Maps an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>) from the specified writer to an x:Class activity tree.

CreateReader

Overloaded. Maps an x:Class activity tree to an DynamicActivity or DynamicActivity<(Of <(TResult>)>).

Load

Overloaded. Creates an instance of a declarative workflow.

Top

Load is used to generally take some XAML and return an Activity which you can then use to execute. If Load encounters a XAML stream for <Activity x:Class, it will subsequently generate a DynamicActivity. This functions basically the same way WorkflowXamlServices.Load() did in beta1.

You also see CreateBuilderReader, and CreateBuilderWriter, which are used to surface the DesignTimeXaml capabilities that we used in beta1. These will return an instance of a XamlReader/Writer that handles the transformation between the metatype and the <Activity x:Class XAML. The metatype has changed names from ActivitySchemaType to ActivityBuilder.

The table below should help summarize the uses and changes between beta1 and beta2. In this area, I don’t expect any changes between what you see now, and what you will see in RTM.

Task	Beta1	Beta2
metatype (type to build types)	ActivitySchemaType	ActivityBuilder
Mechanism to load DynamicActivity	WorkflowXamlServices.Load()	ActivityXamlServices.Load()
Mechanism to load ActivityBuilder	use WorkflowDesigner.Load() to get an ActivitySchemaType	Use the reader from CreateBuilderReader() to pass into XamlServices.Load()
Mechanism to save ActivityBuilder to XAML	Create a new DesignTimeXamlWriter, pass that to XamlServices.Save()	Use the writer returned from CreateBuilderWriter() to pass into XamlServices.Save()

To explore this, use CreateBuilderReader() and XamlServices.Load() on a workflow that you’ve built in the designer and poke around a bit to see what’s going on.

Here is some sample code that walks through this:

   1:  ActivityBuilder ab1 = new ActivityBuilder();

   2:  ab1.Name = "helloWorld.Foo";

   3:  ab1.Properties.Add(new DynamicActivityProperty { Name = "input1", Type = typeof(InArgument<string>) });

   4:  ab1.Properties.Add(new DynamicActivityProperty { Name = "input2", Type = typeof(InArgument<string>) });

   5:  ab1.Properties.Add(new DynamicActivityProperty { Name = "output", Type = typeof(OutArgument<string>) });

   6:  ab1.Implementation = new Sequence

   7:  {

   8:      Activities =

   9:      {

  10:          new WriteLine { Text = "Getting Started " },

  11:          new Delay { Duration = TimeSpan.FromSeconds(4) },

  12:          new WriteLine { Text = new VisualBasicValue<string> { ExpressionText= "input1 + input2" }},

  13:          new Assign<string> { To = new VisualBasicReference<string> { ExpressionText = "output" },

  14:                       Value = new VisualBasicValue<string> {ExpressionText= "input1 + input2 + \"that's it folks\"" } }

  15:      }

16:

  17:  };

  18:  StringBuilder sb = new StringBuilder();

  19:  StringWriter tw = new StringWriter(sb);

  20:  XamlWriter xw = ActivityXamlServices.CreateBuilderWriter(

  21:      new XamlXmlWriter(tw, new XamlSchemaContext()));

  22:  XamlServices.Save(xw , ab1);

  23:  string serializedAB = sb.ToString();

24:

  25:  DynamicActivity da2 = ActivityXamlServices.Load(new StringReader(serializedAB)) as DynamicActivity;

  26:  var result = WorkflowInvoker.Invoke(da2, new Dictionary<string,object> { {"input1","hello"}, {"input2", "world" }});

  27:  Console.WriteLine("result text is {0}", result["output"]);

28:

29:

  30:  ActivityBuilder ab = XamlServices.Load(

  31:      ActivityXamlServices.CreateBuilderReader(

  32:          new XamlXmlReader(new StringReader(serializedAB)))) as ActivityBuilder;

33:

  34:  Console.WriteLine("there are {0} arguments in the activity builder", ab.Properties.Count);

  35:  Console.WriteLine("Press enter to exit");

  36:  Console.ReadLine();

Good luck, and happy metatyping!

Navigating the WF4 Beta 2 Samples

mwinkle — Thu, 22 Oct 2009 19:25:04 GMT

Hot off the presses (and the download center) come the WF4 Beta 2 samples here. The team has invested a lot of time into these samples and they provide a good way to get up to speed on the way a particular feature or group of features work together.

Note, there are 2300 files to be unzipped, so hopefully there is a sample in here for everyone.

At a high level, we work down the directory structure from technology, sample type, and then some functional grouping of samples.

Within the “Sample Type” we have a few different categories we use.

Basic

These are “one feature” samples that are used to illustrate how to use a given sample. Often times they are hosted in the most basic wrapper necessary in order to get the feature to a point where it can be shown.
These are grouped within feature level areas, a few examples from the samples are:

\WF\Basic

\BuiltInActivities – how to configure and use the activities that are in the box
\CustomActivities

\CodeBodied\ – writing activities in code, including async, composite, and leveraging ActivityAction’s
\Composite – writing composite activities
\CustomActivityDesigners – writing activity designers

\Designer – programming against the infrastructure, a tree view designer, and a XamlWriter which will remove view state.
\Persistance
\Tracking

Scenario

These are higher level samples that require pulling together a number of features in order to highlight how the features can be combined to enable an application of the technology that might be of interest. In the WF bucket, you will see things like Compensation and Services, which pull together a number of individual features
The ActivityLibrary folder is chock full of interesting sample activities that are useful for seeing how to write activities, as well as code that might be useful in your application. Some of these are items which we aren’t shipping in the framework but may in the future. Many of these also include interesting designers as well. Some of the interesting sample activities in here:

Application

These samples are used to show how to pull everything together within the context of an application. For instance, the WorkflowSimulator is described this way:

This sample demonstrates how to write a workflow simulator that displays the running workflow graphically. The application executes a simple flowchart workflow (defined in Workflow.xaml) and re-hosts the workflow designer to display the currently executing workflow. As the workflow is executed, the currently executing activity is shown with a yellow outline and debug arrow. In addition tracking records generated by the workflow are also displayed in the application window. For more information about workflow tracking, see Workflow Tracking and Tracing. For more information about re-hosting the workflow designer, see Rehosting the Workflow Designer.

The workflow simulator works by keeping two dictionaries. One contains a mapping between the currently executing activity object and the XAML line number in which the activity is instantiated. The other contains a mapping between the activity instance ID and the activity object. When tracking records are emitted using a custom tracking profile, the application determines the instance ID of the currently executing activity and maps it back to the XAML file that instantiated it. The re-hosted workflow designer is then instructed to highlight the activity on the designer surface and use the same method as the workflow debugger, specifically drawing a yellow border around the activity and displaying a yellow arrow along the left side of the designer

Extensibility

This is a section inside the WCF samples that focuses on the various mechanisms and levels of extensibility

I will be blogging more on some of the interesting (to me) individual samples. What do you think? Are there samples you’d like to see? How are you using these, is there anything we can do to make these more useful?

WF4 Designer Enhancements in VS 2010 Beta 2

mwinkle — Tue, 20 Oct 2009 17:10:24 GMT

So, you might have heard that Beta2 has shipped. I wanted to give a brief overview of the changes that have been made to the designer since beta1.

So, without further ado, here are my top 10 new designer features in Beta 2

New UI
Expand in place
Choose Toolbox Items
Imports designer
Text on Flowchart labels
IActivityTemplateFactory is public
Namespace change
WriteLine designer
UI Virtualization
Information about arguments in the property grid

New UI

We made a decision in Beta2 to do a bit of an overhaul on the designers general theme and feel in order to feel more like part of VS. The UI we had in Beta1 was still the first pass at the designer surface that we showed last year in the first CTP at PDC. Here are some screenshots of that new UI. Our UX PM, Cathy, has started a blog, and I expect she will have some really interesting discussions about the design decisions that we made.

We’ve rounded out the set of icons as well

We’ve also created focus around the header, and surface information within that header (like validation errors)

Expand in Place

One of the biggest pieces of feedback that we got from the Beta1 release was the need to see what’s going on in my workflow. The model we had in Beta1 was optimized around a few levels of composition, and required the user to double-click to drill into the activity. This model works well to focus on an activity, but comes at the expense of the broader view. We’ve gone ahead and changed that in beta2 that allows the workflow items to expand in place.

I am jazzed that we did this, and there is no good way to put it in a picture. Open up the designer and start playing around, and I think you’ll like what you’ll see. The other nice part of this is that I can still choose to drill into if I want to have that focus. This should also support fairly deep nesting of activities, meaning you can visualize large, complex workflows on the canvas.

Additionally, you can choose to expand or collapse individual nodes, or go to the “Expand All” command in order to expand out the tree. One thing to note is that we don’t allow expansion inside of a flowchart because we don’t yet have a mechanism that lets me rearrange all of the items around that newly expanded activity.

Choose Toolbox Items

If you have an assembly on disk somewhere that contains some activities, you can now add it into the toolbox through the Choose Items dialog.

When you drop these new items on the canvas, the appropriate reference should be wired up for you.

Imports Designer

One thing that we heard from folks is that they like the vb expressions (well, they like the expressions, they aren’t super excited that we only have one language choice at this point), but they really didn’t like fully qualifying the type names. To help out with this, we’ve introduced the Imports designer which lets you pick out the namespaces you want to import that will be used to make it easier to resolve types.

Before:

Go to the Imports designer down at the bottom (next to Arguments and Variables) and add System.Xml

This will now bring in System.Xml into the expression text box:

Text on Flowchart Labels

People seem to like the flowchart model, but one request we heard was that it was tough to see what all the lines meant, especially coming out of the branching constructs. I’ll show a few other interesting flowchart things here.

First, hovering over a switch/decision will show the expression

Clicking on the small triangle will “pin” this expression so that I can see it while working on the flowchart. Now, hook up some of the lines:

We also heard that the labels True and False are descriptive for the decision, they may not capture the intent. So, you can click on the decision, open the property grid and set these to some custom value.

Switch will display the switch values as well.

IActivityTemplateFactory is Public

Towards the end of Beta1, we slipped a little feature in called IActivityTemplateFactory as an internal API to generate a configured set of activities (like what happens when I drop the messaging activity pairs). We found a number of folks really liked this idea, so we have made this public. This lets you add these factories to the toolbox to drop a templatized, configured set of activities onto the canvas. A real simple one would look like [this drops a Pick with two branches, like what happens today when you drop a Pick]:

   1:  public sealed class PickWithTwoBranchesFactory : IActivityTemplateFactory

   2:  {

   3:      public Activity Create(DependencyObject target)

   4:      {

   5:          return new Pick

   6:          {

   7:              Branches =

   8:              {

   9:                  new PickBranch

  10:                  {

  11:                      DisplayName = "Branch1"

  12:                  },

  13:                  new PickBranch

  14:                  {

  15:                      DisplayName = "Branch2"

  16:                  }

  17:              }

  18:          };

  19:      }

  20:  }

Namespace change

We’ve made some OM changes (there have been some I’ll blog about later). One important one is that we needed to move out of the *.Design namespaces, primarily because *.Design is meant to specifically imply VS designer specific stuff, and our designer stuff is not VS specific. So, we’ve moved from .Design to .Presentation as our namespace and assembly names of choice. There has also been some reduction in the number of namespaces, and moving some types out of the root namespace (System.Activities.Presentation) into more specialized namespaces (System.Activities.Presentation.Converters).

We’ve also reduced the number of assemblies from 3 to 2, and here is the way to think about them.

System.Activities.Presentation.dll => this is the core extensibility mechanism and the bulk of the “guts” of the designer
System.Activities.Core.Presentation.dll => this is primarily the assembly that contains the designers for the out of box activity designers. There are some, but not too many extensibility / programmability points.
- One thing to note is that the out of box designers have been made internal as there isn’t any extensibility built into those.

Within System.Activities.Presentation.dll, here are the public namespaces:

System.Activities.Presentation
.Converters
.Debug
.Hosting
.Metadata
.Model
.PropertyEditing
.Services
.Toolbox
.Validation
.View

Writeline Designer

We had not originally planned for a designer for WriteLine, we had felt that the default designer was good enough for this. We heard some feedback and one of the testers decided to put one together. This makes it easy to configure the WriteLine on the canvas:

UI Virtualization

This is a feature you may not see, or ever need to think about, but it’s one that I think is pretty neat, and helps us increase performance for large workflows. We’ve built up some infrastructure inside the designer that supports virtualization of the UI surface. The way to think about this is lazy loading the visuals of the designer until they are actually needed. While this isn’t that useful for a small workflow, as a workflow starts to span multiple screens, it makes sense to only load the visual elements that are required for the workflow that are actually in view. You may see artifacts of this if you open a large workflow as you see some of the workflow “draw on the fly.” The advantages of doing this are that bigger workflows will open faster with fewer visual elements on the screen. The information used by virtualization is coupled with the viewstate of the workflow in order to cache the size of the elements in order to reduce the need to do complex computations about size, position and overlap.

Information About Arguments in the Property Grid

Now, on hover we will display the information about the arguments and properties of the selected item, and additionally, we will pick up the System.ComponentModel.DesscriptionAttribute data as well. The following code:

   1:  public sealed class MySimpleActivity : CodeActivity

   2:  {

   3:      [Description("This is a basic argument which will be used to compute the end value")]

   4:      public InArgument<string> Text { get; set; }

5:

   6:      protected override void Execute(CodeActivityContext context)

   7:      { ...

will show up like this in the property grid:

Bonus Feature: Additional Toolbox Organization

Rather than go with the “big flat list” approach, we’ve made the organization of items in the toolbox a little more granular. This also shows some of the updated icons for the activities :-)

I’m really excited that beta2 is out the door, and I can’t wait to start hearing about folks using it. I’ll start blogging a little more, and there are a few folks on my team that will start talking about some other interesting designer topics.

Introduction to WF Designer Rehosting (Part 2)

mwinkle — Wed, 17 Jun 2009 20:18:26 GMT

standard beta disclaimer. This is written against the beta1 API’s. If this is 2014, the bits will look different. When the bits update, I will make sure to have a new post that updates these (or points to SDK samples that do)

In yesterday’s post, we went over the core components of the designer. Let’s now take that and build that rehosts the designer, and then we’ll circle back around and talk about what we did and what comes next.

Start VS, Create a new project, and select a WPF project

Inside the VS project add references to the System.Activities.* assemblies. For now, that list looks like

System.Activities.dll
System.Activities.Design.Base.dll
System.Activities.Design.dll
System.Activities.Core.Design.dll

You might think the list of design assemblies is excessive. We’ll be collapsing probably into two design assemblies, one with the designer infrastructure and one with the activity designers in subsequent milestones.

Create some layout in the WPF window to hold the various designer elements. I usually do a three column grid for toolbox, property grid and designer canvas.

The XAML for this looks roughly like this:

<Window x:Class="BlogPostRehosting.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Window1" Height="664" Width="831">
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="1*"/>
            <ColumnDefinition Width="3*"/>
            <ColumnDefinition Width="2*"/>
        </Grid.ColumnDefinitions>
    </Grid>
</Window>

Now that we’ve got the layout down, let’s get down to business. First let’s just get an app that displays the workflow designer and then we will add some other interesting features. We wanted to make it easy to get a canvas onto your host application, and to program against it. The key type that we use is WorkflowDesigner, this encapsulates all of the functionality, and operating context, required. Let’s take a quick look at the type definition

Name	Description
Context	Gets or sets an EditingContext object that is a collection of services shared between all elements contained in the designer and used to interact between the host and the designer. Services are published and requested through the EditingContext.
ContextMenu	Gets the context menu for this designer.
DebugManagerView	Provides a DebuggerServicethat is used for runtime debugging.
PropertyGridFontAndColorData	Sets the property grid font and color data.
PropertyInspectorView	Returns a UI element that allows the user to view and edit properties of the workflow.
Text	Gets or sets the XAML string representation of the workflow.
View	Returns a UI element that allows the user to view and edit the workflow visually.

The editing context is where we will spend more time in the future, for now the View is probably what’s most interesting, as this is the primary designer canvas. There are also some useful methods to load and persist the workflow as well.

Let’s start off real simple, and write some code that will display a basic sequence, and we’ll get more sophisticated as we go along.

   1:  using System.Windows;

   2:  using System.Windows.Controls;

   3:  using System.Activities.Design;

   4:  using System.Activities.Core.Design;

   5:  using System.Activities.Statements;

6:

   7:  namespace BlogPostRehosting

   8:  {

   9:      /// <summary>

  10:      /// Interaction logic for Window1.xaml

  11:      /// </summary>

  12:      public partial class Window1 : Window

  13:      {

  14:          public Window1()

  15:          {

  16:              InitializeComponent();

  17:              LoadWorkflowDesigner();

  18:          }

19:

  20:          private void LoadWorkflowDesigner()

  21:          {

  22:              WorkflowDesigner wd = new WorkflowDesigner();

  23:              (new DesignerMetadata()).Register();

  24:              wd.Load(new Sequence

  25:                              {

  26:                                  Activities =

  27:                                  {

  28:                                      new Persist(),

  29:                                      new WriteLine()

  30:                                  }

  31:                              });

  32:              Grid.SetColumn(wd.View, 1);

  33:              grid1.Children.Add(wd.View);

  34:          }

  35:      }

  36:  }

Let’s walk through this line by line:

Line 22, construct the workflow designer
Line 23, Call Register on the DesignerMetadata class. Note that this associates all of the out of the box activities with their out of the box designers. This is optional as a host may wish to provide custom editors for all or some of the out of box activities, or may not be using the out of box activities.
Line 24-31, Call Load, passing in an instance of an object graph to display. This gives the host some flexibility, as this instance could come from XAML, a database, JSON, user input, etc. We simply create a basic sequence with two activities
Line 32, set the column for the view
Line 33, add the view to the display

This gives us the following application:

Now, that was pretty simple, but we’re also missing some key things, namely, the property grid. It’s important to note however that this has all of the functionality of the designer (the variables designer, the overview map, etc. This will react just the same as if you were building the workflow in VS.

Let’s add the property grid by adding the following two lines:

Grid.SetColumn(wd.PropertyInspectorView, 2);
grid1.Children.Add(wd.PropertyInspectorView);

This will let us see the property grid (so things get a little more interesting).

So, we’re able to display the workflow and interact with it, but we probably also want to have a constrained authoring experience (not just editing), so that comes in the form of the ToolboxControl. For the sake of this blog post, we’ll use this in XAML, but we certainly can code against it imperatively as well.

<Window x:Class="BlogPostRehosting.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:sad="clr-namespace:System.Activities.Design;assembly=System.Activities.Design"
        xmlns:sys="clr-namespace:System;assembly=mscorlib"
        Title="Window1" Height="664" Width="831">
    <Window.Resources>
        <sys:String x:Key="AssemblyName">System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</sys:String>
    </Window.Resources>
    <Grid Name="grid1">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="1*"/>
            <ColumnDefinition Width="3*"/>
            <ColumnDefinition Width="2*"/>
        </Grid.ColumnDefinitions>
        <sad:ToolboxControl>
            <sad:ToolboxControl.Categories>
                <sad:ToolboxCategoryItemsCollection CategoryName="Basic">
                    <sad:ToolboxItemWrapper AssemblyName="{StaticResource AssemblyName}" ToolName="System.Activities.Statements.Sequence"/>
                    <sad:ToolboxItemWrapper AssemblyName="{StaticResource AssemblyName}" ToolName="System.Activities.Statements.If"/>
                    <sad:ToolboxItemWrapper AssemblyName="{StaticResource AssemblyName}" ToolName="System.Activities.Statements.Parallel"/>
                    <sad:ToolboxItemWrapper AssemblyName="{StaticResource AssemblyName}" ToolName="System.Activities.Statements.WriteLine"/>
                    <sad:ToolboxItemWrapper AssemblyName="{StaticResource AssemblyName}" ToolName="System.Activities.Statements.Persist"/>
                </sad:ToolboxCategoryItemsCollection>
            </sad:ToolboxControl.Categories>
        </sad:ToolboxControl>
    </Grid>
</Window>

This lets me specify the items I want to allow a user to drop.

The thing that is interesting to point out here is that we’ve built a full featured, constrained editor (with things like copy paste, undo/redo, etc) with not too much code.

Next time, we’ll get into to doing some more interesting bits as well to interact with the item being edited, serialize to XAML, and explore the editing context some more. Let me know what you think!

	Name	Description
	CreateBuilderReader	Overloaded. Maps an x:Class activity tree to an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>).
	CreateBuilderWriter	Maps an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>) from the specified writer to an x:Class activity tree.
	CreateReader	Overloaded. Maps an x:Class activity tree to an DynamicActivity or DynamicActivity<(Of <(TResult>)>).
	Load	Overloaded. Creates an instance of a declarative workflow.