Matt W's Windows Workflow Place

Thoughts on Flowchart

mwinkle — Fri, 13 Aug 2010 22:45:26 GMT

Last night I saw that Maurice had a few tweets that caught my attention about flowchart, but this is the one that I want to talk about:

Come to think of it I also really mis a parallel execution in a flowchart. But other than that flowcharts rock! #wf4 #dmabout 13 hours ago via web

I thought about replying on twitter, but it’s a bit of a longer topic. When we were building the flowchart for VS2010, we considered a number of possible capabilities, but ultimately the capabilities customers were looking for fell into two categories:

Arbitrary rework patterns
Coordination patterns

Arbitrary Rework

We can describe the model of execution in the current flowchart to be one that supports arbitrary rework. You could also refer to this as GOTO. One benefit (and downside) of breaking out of the tightly scoped, hierarchical execution model that we see with the Sequential style of workflows (and in most procedural languages) is the fact there exists more freedom in terms of defining the “next” step to be taken. The simplest way to think about this is the following flowchart:

Now, this isn’t particularly interesting, and most folks who look at this will simply ask “why not a loop?” which in this case is a valid question. As a process gets more sophisticated (or if humans tend to be involved), the number of possible loops required gets rather tricky to manage in a sequential flow (consider the following rework scenario which includes “next steps” across conditional boundaries, and from some branches but not others.

Now, mathematically, we can describe the machinery in both of these machines as a set of valid transitions, and it is likely possible that there exists a complete mapping from any flowchart into procedural.

Coordination

The second pattern we consistently saw was the use of a free form style of execution in order to build complex coordination patterns. The example I consistently return to (pointing back to a blog post I made back in the WF3 days)

Here I want to be able to coordinate a few different things, namely that 3 executes when 1 completes, 5 when 2, 4 when 1 AND 2, 6 when 3 AND 4 AND 5 complete. Here we’ve created a dependency graph that can’t be handled with the procedural constructs that we have. How could this happen? Imagine we’re trying to model the ranking process for a series of horse races. Task 3 can happen when Race 1 completes, as Task 5 can happen when Race 2 completes. Task 4 represents some work that requires the data from both Races. When those 3 tasks (3, 4, and 5) complete, I can move forward and take some action (like bet on the next race).

This type of pattern can be very powerful, and is often described by petri-nets. There exists a multitude of join semantics from simple AND joins to conditional joins (ranging from a simple “count” to a condition based on data).

How’d we get to where we are today?

Today, the flowchart in the .NET framework only supports the former pattern, that of arbitrary rework. How’d we get there. While we found a lot of value in both patterns what we found when we tried to compose them, we often got into places that became very hard to have predictable execution semantics. The basic crux of the design issue gets to the “re-arming” of a join. If I decide to jump back to task 3 at some point, what does it mean for 3 to complete? Do I execute 6 again right away, do I wait for 4 and 5 to complete a second time? What happens if I jump to 3 a second time? Now, there certainly exist formal models for this, and things like Petri-net define a set of semantics for these things. What we found though was that any expression of the model that took these things into account required a pretty deep understanding of the process model, and we lost one of the key benefits we see from a flowchart, which is that it is a simple, approachable model. This is not to say that we don’t think that the Coordination pattern is useful, or that petri-nets don’t ultimately hold the unified approach, we just did not have the time to implement a coordination pattern in VS 2010, and creating an approachable petri-net backed flowchart modeling style was something we’d need more time to get correct.

Where does this leave us?

If you’re looking at this and saying, “but I want coordination (or a full blown petri-net)”, there are a couple of options:

Roll up your sleeves and write that activity. In the blog post above, I outline how you could go about building the coordination pattern, and with the new activity model, this would be simpler. The harder part is still writing a designer, and there is now some good guidance on free form designers in the source of the state machine on codeplex.
Provide feedback on connect, when you do this it opens a bug in our bug database that our team is looking at daily. Describe your scenario, what you’re trying to do, and what you’d like to see. This type of customer feedback is vital to helping us plan the right features for the next release.

Improving ModelItem with Dynamic

mwinkle — Wed, 11 Aug 2010 17:22:40 GMT

Hi all, I’m back, and apologize for the delay, things have been crazy here and I’ve taken a little time off following shipping VS2010, so I’m getting back into it. I’d like to talk about one of my favorite late additions to the WF4 designer programming model. We added this change sometime in the RC/RTM timeframe in response to some feedback that we had gotten about the verbose-ness of programming against ModelItem.

If you recall from this post, ModelItem exists to serve as a INotifyPropertyChanged (INPC) aware proxy to the underlying instance being edited within the designer. In exchange for this fairly flexible proxy layer, you get in return a pretty verbose way in which one has to interact to actually get to the data. Often times there are fairly long incantations of myModelItem.Properties[“foo”].Value.Properties[“bar”].Value.GetCurrentValue() in order to actually return the data (or be able to set the value). From the beginning, we had decided we wanted to optimize for the WPF XAML consumer of the model item, and so we chose to implement ICustomTypeDescriptor so that WPF binding would be pretty simple (the above would result in a binding syntax of ModelItem.foo.bar).

One quick note, looking at the definition of ModelItem itself will show that only the INPC interface is implemented. However, ModelItem is an abstract type, and the implementation subclass ModelItemImpl contains the definition and implementation of the following interfaces ModelItem, IModelTreeItem, ICustomTypeDescriptor, IDynamicMetaObjectProvider

As we worked with some of our customers, it became clear that they were frequently using ModelItem in code as well, and so the programming model was becoming more of a problem (we had somewhat hoped that the majority of customers would be using XAML). We initially went with the idea that we would create a series of Design time peers to all of the common types in WF (making a SequenceDesign, ParallelDesign, etc) which provided an identical programming surface to its peer, but under the covers in the property getters and setters would redirect to an underlying ModelItem. This has the advantage that we could create the appearance of a strongly typed API surface, but has the downside that it introduces an extra type for every activity we ship, and it requires customers to create two types as well, and not just for activities, you would want one for customer too. The other approach we kicked around was using the Dynamic capabilities introduced in .NET 4.

It’s important to note that these are ultimately complimentary approaches, that is, it’s possible in a future framework release (or in a codeplex project if anyone is looking to for a little fun on the side) you could release the strongly typed design time peers. From a timing perspective, it was not likely that we could introduce 30+ new types in the RC/RTM release, and we had questions about the long term sustainability of requiring an additional type for activities. So, we went ahead with the plan for dynamic support. In order to do this, we had to add an implementation of IDynamicMetaObjectProvider. Bill Wagner has a good article here on the basics of doing this. This requires us to implement one method, GetMetaObject. In our case, we have an internal, nested ModelItemMetaObject type which inherits from System.Dynamic.DynamicMetaObject.

In our case, there are basically two important methods that we care about, BindGetMember and BindSetMember. These wire up to two methods on ModelItemImpl to get and set based on the property name. The net result of this is that the following code

root.Properties["Residence"].
        Value.
        Properties["StreetAddress"].
        Value.GetCurrentValue()

Can now be written as

dynamic mi = root;
Console.WriteLine(root.Residence.StreetAddress)

Now, with anything there are some tradeoffs, the biggest one is that this is dynamic, I don’t get compile time checking, and I could have a type that will result in an exception being thrown (that said, that problem exists in the verbose form as well). This does let me write much more succinct code when programming the model item tree though for both gets and sets. As an added bonus, we found there is actually a decent perf improvement from the WPF XAML data binding that now leverages the IDynamicMetaObjectProvider (mentioned in ScottGu’s post here) in the way that the runtime will only compute the way to resolve the property once (as opposed to every time when it goes through the ICustomTypeDescriptor code path).

Enjoy!

VS 2010 RC Is Available

mwinkle — Tue, 09 Feb 2010 22:09:36 GMT

We’ve been hard at work here in Redmond (and with our team in Shanghai) working on getting WF ready for release. We’ve made a ton of progress in the RC build that was made available yesterday, please download it and check it out. Also, and in important bold text, if you have feedback, please, please, please file an issue on Connect so that the team can look at it right away. One thing that I want to point out about Connect is that it is not a vacuum, the entries there go directly into our bug tracking system, which we look at daily in our various shiproom meetings. If something isn’t working right, please let us know!

We’ve fixed a number of issues that came directly from Connect in this last milestone, including some areas that revealed some gaps in our testing. Your feedback is making this better. For bugs that we’ve marked as postponed, as we start planning for vNext, we will start going through those to figure out the areas we need to improve on.

It’s cool the home stretch, this morning I presented to our support team to get them prepared to handle any PSS incidents that occur. It’s great to see the release coming together.

Making Swiss Cheese Look Good, or Designers for ActivityAction in WF4

mwinkle — Fri, 15 Jan 2010 00:06:54 GMT

In my last post, I covered using ActivityAction in order to provide a schematized callback, or hole, for the consumers of your activity to supply. What I didn’t cover, and what I intend to here, is how to create a designer for that.

If you’ve been following along, or have written a few designers using WorkflowItemPresenter, you may have a good idea how we might go about solving this. There are a few gotcha’s along the way that we’ll cover as we go through this.

First, let’s familiarize ourselves with the Timer example in the previous post:

using System;

using System.Activities;

using System.Diagnostics;

namespace WorkflowActivitiesAndHost

    public sealed class TimerWithAction : NativeActivity<TimeSpan>

        public Activity Body { get; set; }

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

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

        public TimerWithAction()

            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);

So, let’s build a designer for this. First we have to provide a WorkflowItemPresenter bound to the .Body property. This is pretty simple. Let’s show the “simple” XAML that will let us easily drop something on the Body property

<sap:ActivityDesigner x:Class="actionDesigners.ActivityDesigner1"
    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">
    <StackPanel>
        <sap:WorkflowItemPresenter 
                 HintText="Drop the body here" 
                 BorderBrush="Black" 
                 BorderThickness="2" 
                 Item="{Binding Path=ModelItem.Body, Mode=TwoWay}"/>
        <Rectangle Width="80" Height="6" Fill="Black" Margin="10"/>
    </StackPanel>
</sap:ActivityDesigner>

Not a whole lot of magic here yet. What we want to do is add another WorkflowItemPresenter, but what do I bind it to? Well, let’s look at how ActivityDelegate is defined [the root class for ActivityAction and ActivityFunc (which I’ll get to in my next post).:

hmmm, Handler is an Activity, that looks kind of useful. Let’s try that:

[warning, this XAML won’t work, you will get an exception, this is by design :-) ]

<sap:ActivityDesigner x:Class="actionDesigners.ActivityDesigner1"
    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">
    <StackPanel>
        <sap:WorkflowItemPresenter HintText="Drop the body here" BorderBrush="Black" BorderThickness="2" Item="{Binding Path=ModelItem.Body, Mode=TwoWay}"/>
        <Rectangle Width="80" Height="6" Fill="Black" Margin="10"/>
<!-- this next line will not work like you think it might --> 
        <sap:WorkflowItemPresenter HintText="Drop the completion here" BorderBrush="Black" BorderThickness="2" Item="{Binding Path=ModelItem.OnCompletion.Handler, Mode=TwoWay}"/>

    </StackPanel>
</sap:ActivityDesigner>

While this gives us what we want visually, there is a problem with the second WorkflowItemPresenter (just try dropping something on it):

Now, if you look at the XAML after dropping, the activity you dropped is not present. What’s happened here:

The OnCompletion property is null, so binding to OnCompletion.Handler will fail
We (and WPF) are generally very forgiving of binding errors, so things appear to have succeeded.
The instance was created fine, the ModelItem was created fine, and the it was put in the right place in the ModelItem tree, but there is no link in the underlying object graph, basically, the activity that you dropped is not connected
Thus, on serialization, there is no reference to the new activity in the actual object, and so it does not get serialized.

How can we fix this?

Well, we need to patch things up in the designer, so we will need to write a little bit of code, using the OnModelItemChanged event. This code is pretty simple, it just means that if something is assigned to ModelItem, if the value of “OnCompletion” is null, initialize it. If it is already set, we don’t need to do anything (for instance, if you used an IActivityTemplateFactory to initialize). One important thing here (putting on the bold glasses) YOU MUST GIVE THE DELEGATEINARGUMENT A NAME. VB expressions require a named token to reference, so, please put a name in there (or bind it, more on that below).

using System;
using System.Activities;

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

        protected override void OnModelItemChanged(object newItem)
        {
            if (this.ModelItem.Properties["OnCompletion"].Value == null)
            {
                this.ModelItem.Properties["OnCompletion"].SetValue(
                    new ActivityAction<TimeSpan>
                    {
                        Argument = new DelegateInArgument<TimeSpan>
                        {
                            Name = "duration"
                        }
                    });
            }
            base.OnModelItemChanged(newItem);

        }
    }
}

Well, this works :-) Note that you can see the duration DelegateInArgument that was added.

Now, you might say something like the following “Gosh, I’d really like to not give it a name and have someone type that in” (this is what we do in our ForEach designer, for instance). In that case, you would need to create a text box bound to OnCompletion.Argument.Name, which is left as an exercise for the reader.

Alright, now you can get out there and build activities with ActivityActions, and have design time support for them!

One question brought up in the comments on the last post was “what if I want to not let everyone see this” which is sort of the “I want an expert mode” view. You have two options. Either build two different designers and have the right one associated via metadata (useful in rehosting), or you could build one activity designer that switches between basic and expert mode and only surfaces these in expert mode.

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!

Subscription / Notification Engine (WF4 EditingContext Intro Part 5)

mwinkle — Tue, 22 Dec 2009 21:20:08 GMT

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

In this post, we’re going to tie together a few of the things we’ve seen in the last few posts and show how we can wire up parts of the designer (or the hosting application) to changes made to the Items collection of the EditingContext to do some interesting things.

You will note that both the ServiceManager and ContextItemManager have Subscribe methods, and I’ve talked in previous posts about how the publish mechanism is a little different. I want to dive a little deeper into how these work, the different overloads, and what you can expect have happen on the subscribe side of things.

Services

On service, there are two different publish methods. I will list all four, and then talk about how there are really only two :-)

Method	Description
Publish(Type, PublishServiceCallback)	Publishes the specified service type, but does not declare an instance. When the service is requested, the Publish service callback will be invoked to create the instance. The callback is invoked only once. After that, the instance it returned is cached.
Publish(Type, Object)	Publishes the given service. After it is published, the service instance remains in the service manager until the editing context is disposed of.
Publish<(Of <(TServiceType>)>)(TServiceType)	Publishes the given service. After it is published, the service instance remains in the service manager until the editing context is disposed of.
Publish<(Of <(TServiceType>)>)(PublishServiceCallback<(Of <(TServiceType>)>))	Publishes the given service type, but does not declare an instance yet. When the service is requested, the PublishServiceCallback will be invoked to create the instance. The callback is invoked only once. After that, the instance it returned is cached.

There are really only two methods here, and some generic sugar for the other two. They are Publish(Type, PublishServiceCallback), and Publish(Type, Object). If you were to look at the implementation of the generic versions, they simply turn around and call the un-generic form.

The difference between the basic one (Publish(Type, Object)) and the version with the callback is that the callback enables us to be a little more lazy and wait to actually create the instance of the object until it is first requested. Let’s look at how PublishServiceCallback is defined:

public delegate Object PublishServiceCallback(
    Type serviceType
)

What this lets us do is that the first time someone calls GetService, this method will be called with the responsibility of returning an instance of the service type. Subsequent calls to GetService will simply return the instance returned by the method provided fro the PublishServiceCallback. It is important to note that on Publish, any subscribers will be notified. As the Subscribe callback takes an instance, we will internally call GetService on the notification, which will in turn call the PublishServiceCallback to instantiate an object. If we have subscribers, our publish is less lazy (but that’s by design, we have consumers who are ready and waiting to consume).

Let’s now look at the subscribe methods. Again, here there are two methods (generic and non-generic), but they both do the same thing:

Method	Description
Subscribe	Invokes the provided callback when someone has published the requested service. If the service was already available, this method invokes the callback immediately.
Subscribe<(Of <(TServiceType>)>)	Invokes the provided callback when someone has published the requested service. If the service was already available, this method invokes the callback immediately.

Both of these use a SubscribeServiceCallback defined as the following

public delegate void SubscribeServiceCallback(
    Type serviceType,
    Object serviceInstance
)

This allows any consumer to be notified when a service is initially published. This is an important distinction we will call out versus items which provide a more advanced subscription method (namely, to changes).

Why is this Useful?

Generally we find this useful for a few reasons:

Services may not be available at designer initialization, or the order in which they are created may not be fixed (it is ultimately up to the host to determine this).
Services may be provided by the host. It is possible your activity designer may be used in a host that does not provide that service. You may want to be flexible in handling that
Services can be injected at any time. A publish – subscribe model lets us have a little more flexibility to react to new services as they are added. You could imagine a spell checking service that a host only provides on the first time someone hits “spell check.” When this service comes online, then our designers can decide to consume this.
Flipping things around, you may want to use a service to callout to a host, and you would like the host to subscribe for when an certain activity designer will publish a service.

Now let’s talk about Items:

Items

Items do not have a publish method, per se, but they have the SetValue method which basically publishes an instance to the context. The semantics of SetValue are that it will first attempt to store the new value. Provided that succeeds, we then call OnItemChanged on the ContextItem itself. This is basically notifies the object itself (giving it a chance to react, clean up, or throw if something is really wrong). If this throws, the old value is preserved. If this succeeds, we then notify anyone who has subscribed to the changes.

GetValue allows me to retrieve the ContextItem. There are two GetValue’s, one generic, the other non-generic, but with a type as its parameter. It is important to note the point that is also present in the docs. If there is not an item present when this is called, the default value will be instantiated and returned.

Provided items are written using SetValue, all of the subscribers will be subsequently notified. If I just do an arbitrary GetValue and then make a few changes without calling SetValue, by default nothing interesting is going to happen (that is, no subscribers will be notified, subsequent calls to GetValue will get the updated object however). Subscribe (and it’s generic counterpart) allow me to provide a SubscribeContextCallback which will be invoked whenever SetValue is called. This functions basically in the same way that it does for Services.

An interesting pattern for Items that we use in a few places throughout the designer is to create an AttachedProperty on the modelItem (similar to this post) which in the implementation of the Getter and Setter will call out to the editing context to get or set the value from a ContextItem. This gives me a WPF friendly binding surface (foo.Bar binding syntax) that we can wire up to be change aware. We do this for a number of our triggers within our style implementation for things like is selected, etc. Future post note for me is that I should go through all of the attached properties present on a ModelItem that you could use to bind to :-)

This wraps up a tour of the Subscription / Notification engine present within the EditingContext.

Providing Callbacks for the Host (WF4 EditingContext Intro Part 4)

mwinkle — Tue, 22 Dec 2009 17:57:01 GMT

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

In addition to having a host provide an instance of a type to be used within the designer, it can also be used to pass an instance that will route callbacks to the host. I covered this briefly in a previous post (Displaying Validation Errors in a Rehosted WF4 Designer). In that case, we provide an implementation of IValidationErrorService, which the designer infrastructure will call, if available, towards the end of a completion of a validation episode. In the sample application in that post, we use that instance to route, and display the validation errors in the system.

Rather than duplicate the code, I will simply encourage you to check out that post and think about the way you could publish a service that your activity designers know about, and use it as a mechanism for calling methods within the hosting application.

Host Provided Capabilities (WF4 EditingContext Intro Part 3)

mwinkle — Tue, 22 Dec 2009 17:03:21 GMT

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

Introduction

Sharing Functionality between Designers

Host provided capabilities (you are here)

Providing callbacks for the host

Subscription/Notification engine

Inspection, Default Services and Items

EditingContext is used by our primary hosting application, Visual Studio, to provide concrete implementations of certain services. The example that we will talk about here is the IExpressionEditorService. Now, one thing that we would have really liked to have done in vs2010 is to provide a way to use the intellisense enabled VB editor that you see within VS inside a rehosted app. For various reasons, we were not able to ship with that dependency in the .NET framework. However, we needed a mechanism for our primary host to have the intellisense experience (and similarly, you could build an experience, or maybe we’ll ship one in the future for rehosted apps).

Let’s look at the design of IExpressionEditorService:

Name	Description
CloseExpressionEditors	Closes all the active expression editors.
CreateExpressionEditor	Overloaded. Creates a new expression editor.
UpdateContext	Updates the context for the editing session.

Inside the ExpressionTextBox control, when the control needs to render the editor, it has code that looks like the following (note, if it can’t find an instance, it skips and just uses a plain old text box):

if (this.Context.Services.GetService<IExpressionEditorService>() != null)
{
      return this.Context.Services.GetService<IExpressionEditorService>().CreateExpressionEditor(...)
}

Using the following overload of CreateExpressionEditor:

IExpressionEditorInstance CreateExpressionEditor(
    AssemblyContextControlItem assemblies,
    ImportedNamespaceContextItem importedNamespaces,
    List<ModelItem> variables,
    string text
)

Now, what happens is that inside the code that we ship in the Microsoft.VisualStudio.Activities.Addin.dll, there is both a concrete implementation of this type, as well as the code which will publish an instance of this to the editing context. Remember, this is the same thing that you can do in your app for a these host provided services. In a subsequent post, I will get into more details of what are the ones that the designer has built in (like IExpressionEditorService).

Sharing Functionality Between Designers (WF4 EditingContext Intro Part 2)

mwinkle — Mon, 21 Dec 2009 22:10:24 GMT

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

Setup

We will need a custom activity, EmptyOne and designer called InteractWithServiceDesigner.

using System.Activities;
using System.ComponentModel;

namespace blogEditingContext
{
    [Designer(typeof(InteractWithServicesDesigner))]
    public sealed class EmptyOne : 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);
        }
    }
}

What We Will See

The designers for Foo will leverage a new service in order to display a list of database tables. We will also need to publish this service to the editing context, and handle the fact that we don’t know who might publish it (or when it might be published). Note that in VS, there is no way to inject services except by having an activity designer do it. In a rehosted app, the hosting application could publish additional services (see part 4) that the activities can consume. In this case though, we will use the activity designer as our hook.

Publishing a Service

Let’s look at the designer for Foo (as Foo is our generic, and relatively boring activity).

<sap:ActivityDesigner x:Class="blogEditingContext.InteractWithServicesDesigner"
    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">
    <StackPanel>
        <ListBox Height="100" Name="listBox1" Width="120" />
        <Button Name="button1" Click="Button_Click">Publish Service</Button>
    </StackPanel>
</sap:ActivityDesigner>

Not much to this, except a drop down list that is currently unbound (but a name is provided). Also note that there is a button that says to “publish the service”. Let’s first look at the code for the button click

private void Button_Click(object sender, RoutedEventArgs e)
{
    if (!this.Context.Services.Contains<ISampleService>())
    {
        this.Context.Services.Publish<ISampleService>(new SampleServiceImpl());
    }
}

What are we doing here? We first check if this service is already published using the Contains method. We can do this because ServiceManager implements IEnumerable<Type>.

[update, finishing this sentence.] One could also consume the service using GetService<TResult>. You may also note that there is a GetRequiredService<T>. This is a call that we know won’t return null, as the services we are requesting must be there for the designer to work. Rather than returning null, this will throw an exception. Within the designer, we generally think of one service as required:

ModelService

Let’s look at the definition of the service. Here you can see that we are using both an interface and then providing an implementation of that interface. You could just as easily use an abstract class, or even a concrete class, there is no constraint on the service type.

using System.Collections.Generic;

namespace blogEditingContext
{
    public interface ISampleService
    {
        IEnumerable<string> GetDropdownValues(string DisplayName);
    }

    public class SampleServiceImpl : ISampleService
    {
        public IEnumerable<string> GetDropdownValues(string DisplayName)
        {
            return new string[]  { 
                DisplayName + " Foo", 
                DisplayName + " Bar",
                "Baz " + DisplayName
            } ;
        }
    }

}

If there is not a service present, we will publish an instance of one. This becomes the singleton instance for any other designer that may request it. Right now, we have a designer that can safely publish a service. Let’s look at consuming one

Consuming a Service

Let’s look at some code to consume the service. There are two parts to this. One is simply consuming it, which we already saw above in discussing GetService and GetRequiredService . The second is hooking into the notification system to let us know when a service is made available. In this case, it’s a little contrived, as the service isn’t published until the button click, but it’s good practice to use the subscription mechanism as we make no guarantees on ordering, or timing of service availability.

Subscribing to Service

Here, using the Subscribe<TServiceType> method, we wait for the service to be available. The documentation summarizes this method nicely:

Invokes the provided callback when someone has published the requested service. If the service was already available, this method invokes the callback immediately.

In the OnModelItemChanged method, we will subscribe and hook a callback. The callback’s signature is as follows:

public delegate void SubscribeServiceCallback<TServiceType>(
    TServiceType serviceInstance
)

As you can see, in this callback, the service instance is provided, so we can query it directly. You may ask, “why not in Intialize?” well, there are no guarentees that the editing context will be available at that point. We could either subscribe to context being made available, or just use ModelItemChanged:

protected override void OnModelItemChanged(object newItem)
{
    if (!subscribed)
    {
        this.Context.Services.Subscribe<ISampleService>(
            servInstance =>
            {
                listBox1.ItemsSource = servInstance.GetDropdownValues(this.ModelItem.Properties["DisplayName"].ComputedValue.ToString());
                button1.IsEnabled = false;
            }
            );
        subscribed = true; 
    }
}

This wraps a basic introduction to the ServiceManager type and how to leverage it effectively to share functionality in designers.

Let’s look at a before and after shot in the designer:

Before & After

What about Items?

Items follow generally the same Get, Subscribe, and publish pattern, but rather than publish, there is a SetValue method. If you have “just data” that you would like to share between designers (or between the host and the designer) an Item is the way to go about that. The most commonly used item we’ve seen customers use is the Selection item in order to be able to get or set the currently selected model item.

That’s our tour of basic publish and subscribe with Services and Items.

[updated 12/22/2009 @ 10:23 am to finish an unclear sentence about GetService<>]

[updated 12/22/2009 @ 8:50pm : Link to download sample code is here]

Attachment(s): blogEditingContext.zip

Introduction to the WF4 Designer Editing Context (Part 1)

mwinkle — Mon, 21 Dec 2009 18:02:43 GMT

I want to briefly touch on the editing context and give a little introduction to its capabilities. This is part 1 of a 6 part series

The way to think about the editing context is that it is the point of contact between the hosting application, and the designer (and elements on the designer). In my PDC talk, I had the following slide which I think captures the way to think about how these elements are layered together.

Motivation

The editing context represents the a common boundary between the hosting application and the designer, and the mechanism to handle interaction with the designer (outside of the most common methods that have been promoted on WorkflowDesigner). If you were to look at the implementation of some of the more common methods on WorkflowDesigner, you would see that almost all of these use the editing context in order to get anything done. For instance, the Flush method (and Save which calls Flush) will acquire an IDocumentPersistenceService from the Services collection, and then use that in order to properly serialize the document.

The EditingContext type has two important properties

Items

The Items collection is for data that is shared between the host and the designer, or data that is available to all designers. These need to derive from ContextItem which will provide the mechanism to hook into subscription and change notification. There are a couple of interesting methods on the ContextItemManager type :

Services

Services represent functionality that is either provided by the host for the designer to use, or is used by the designer to make functionality available to all designers within the editor. Generally, these are likely defined as interfaces, but can also be a type. It is then required for an implementation or an instance to be provided. This instance will be shared as a singleton. There are a few interesting methods on the ServiceManager type:

We’ll start walking through these over the next few posts.

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!

A Few Additional Treats @ PDC09

mwinkle — Fri, 13 Nov 2009 21:15:50 GMT

One fun thing we will be doing this year is using the theater in our lounge/booth area to have a few chalk style presentations. These will be brief 30 minute demo/ q&a / conversation sessions with somebody from the product team. These will dive a little deeper and be more interactive about topics we know you’re interested in. We’d love you to come and just ask a ton of questions here:

Thursday, 11:00-11:30 / Future Directions for State Machine Workflows / Alan Ko

Discuss options for using the State Machine modeling style on WF4, and see a demonstration of a WF4-based State Machine design experience.

Thursday, 1-1:30 / Migrating WF 3.5 Workflows to WF 4 / Bob Schmidt

Learn some tips and techniques for migrating your WF 3.5 workflows to the new WF4 runtime, and see a demonstration of a tool that helps automate this process.

Thursday, 2:00-2:30 / WF Rehosting Deep Dive / Kushal Shah

See how WF’s rehostable runtime, designer, and debugger can add powerful capabilities to your applications

I’m excited because we’re going to use this as an opportunity to show some cool stuff that we’re thinking about. Usual disclaimers apply, some of the stuff here we will show are prototypes, ideas we are looking for feedback, etc, etc. These are things that we think are important, and your feedback helps us understand what you really need to make these things useful for you

Stop on by the booth if you’re interested in any of the above topics!

Matt’s PDC Session List

mwinkle — Thu, 12 Nov 2009 05:48:52 GMT

I’m hoping that this PDC might be a little different and I may actually get to attend some sessions, rather than just prepping for mine (or the others from my team). I’ve gone through all 22 pages of published talks, and I think there are some interesting ones. So, without further ado, and with little, if any regard for actual scheduling of talks in relation to mine, here are the talks I would be interested in going to at PDC09.

Hopefully I can get to 10 of them.

Session Name	Comment
Building Data-Driven Applications Using Microsoft Project Code Name "Quadrant" and Microsoft Project Code Name "M"	Doug’s had a few things to say recently, and I think this talk will be interesting. My team was part of the Quadrant team for a while, and I’m curious to see what they’ve been up to.
Windows 7 and Windows Server 2008 R2 Kernel Changes	Anytime that you get to hear Mark talk about the kernel, it’s a great opportunity to learn a lot about a topic we don’t think every day.
Code Visualization, UML, and DSLs	The architecture tools team has done some really, really neat stuff to help you understand your code base better. I've found the tools to be really useful when looking at our code base, and I'd like to learn more here.
Advanced Microsoft SQL Server 2008 R2 StreamInsight	I've been watching StreamInsight since there was an internal talk on the technology. The capabilities here to do high capacity event stream queries is amazing. I think there are a number of interesting classes of problems where this can be useful and I'd like to find out more
Introduction to Microsoft SQL Server 2008 R2 StreamInsight
Dynamic Binding in C# 4	This feature is one that I was excited to hear about in Anders' talk last year. A whole hour on how this works, that's just bliss
Windows Error Reporting	This kind of data is gold for folks who are building software. You can’t catch every bug, or be aware of a video card incompatibility in a certain language on XP SP2, or always know why things might go wrong in your apps. WER gives you a way to get that kind of data.
How Microsoft Visual Studio 2010 Was Built with Windows Presentation Foundation 4	This has been a huge undertaking, and hearing Paul talk about this will be insightful about the challenges faced, the way to integrate large, existing code bases with WPF, native WPF interop, etc.
Windows Presentation Foundation 4 Plumbing and Internals	I have a weak spot for deepdives into plumbing like this talk. This kind of knowledge is so useful for building apps on top of WPF to really understand how the pieces work together and what's happening at the low levels
Future of Garbage Collection	I got to sit next to Patrick at a dinner and had an amazing convesation that knocked my socks off. This is one of the guys who built the GC in .NET, and hearing the way he thinks will be interesting.
Microsoft Perspectives on the Future of Programming	Look at the list of this panel, how could you not want to hear this conversation? Just getting these folks together means there will be some interesting topics with lots of different backgrounds (from Jeffery Snover to Erik Meijer)
REST Services Security Using the Access Control Service	Justin is my former partner in crime from our days as technical evangelists, and I have lunch with him regularly and the stuff that he is working with is wicked cool. He's also one of the best presenters in the company, and there is always something I learn about presenting when I watch him talk.
Data-Intensive Computing on Windows HPC Server with the DryadLINQ Framework	I'd love to see anything that talks about "familiar declarative syntax of LINQ combined with the fault-tolerant distributed graph scheduling of the Dryad runtime"
Building Sensor- and Location-Aware Applications with Windows 7 and the Microsoft .NET Framework 4.0	The location API made me open up my first C++ project in a long time, the range of scenarios that this enables in Win7 is awesome
Code Contracts and Pex: Power Charge Your Assertions and Unit Tests	My first "from the labs" talk on the list, Pex and Code Contracts bring some really compelling capabilities to .NET development. This would be great to see.
Microsoft Application Server Technologies: Present and Future	This is from my team, and I'm excited to see the reaction to some of the cool stuff we will be talking about in the App Server space
Rx: Reactive Extensions for .NET	Erik Meijer is one of those guys I can't get enough of, I'd sign up for the fan club on channel9 if it were available.
Building Amazing Business Applications with Microsoft Silverlight and Microsoft .NET RIA Services	Brad is a really great presenter, and this is a whole space I have not had a chance to pay much attention to. I'd love to learn more about the ways to rapidly create business applications.
SketchFlow: Prototyping to the Rescue	Having just finished a project with a lot of designer/developer interaction, I have a lot of hope for things like SketchFlow.
Developing REST Applications with the .NET Framework	I like watching Don's talks, and REST is kind of a thing these days. Done deal.

Displaying Validation Errors in a Rehosted WF4 Designer

mwinkle — Fri, 06 Nov 2009 18:55:30 GMT

Here’s a quick one

“I’d like to find out if the workflow in the designer is valid… is there someway to retrieve the validation errors?”

Yes, the short answer is that you need to provide an implementation IValidationErrorService. There is one important method to implement on this interface, ShowValidationErrors which will pass you a list of ValidationErrorInfo objects.

The next thing that needs to happen is that you need to publish an instance of that new type to the editing context.

Let’s look at a really simple implementation that will write out the validation errors to the debug log.

using System.Activities.Presentation.Validation;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

namespace VariableFinderShell
{
    class DebugValidationErrorService : IValidationErrorService
    {
        public void ShowValidationErrors(IList<ValidationErrorInfo> errors)
        {
            errors.ToList().ForEach(vei => Debug.WriteLine(string.Format("Error: {0} ", vei.Message)));
        }
    }
}

The final bit is to publish this to the editing context:

wd.Context.Services.Publish<IValidationErrorService>(new DebugValidationErrorService());

Now, when editing the workflow in the rehosted app, let’s introduce some errors and then look at the output window. Note, most of the errors below come from incorrect expressions introduced in the expression editor (putting integers in the wrong place, wrong variable name, etc).

Got a cool .NET app? Hang with Tortoises for 12 days

mwinkle — Fri, 06 Nov 2009 17:15:59 GMT

photo courtesy of flickr user mikeweston

This is a something that the .NET team is putting together that has a contest with super cool prizes (seriously, 12 day trip to the Galapagos, for real (as my 4 year old says)). (obligatory legalese here). If you’ve built a sweet app with the .NET framework, we’d like to hear about it. So check out http://www.myDotNetStory.com today and enter to win.

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.

Deep Dive into the WF4 Designer Data Model: ModelItem and ModelProperty

mwinkle — Wed, 28 Oct 2009 21:50:45 GMT

In this post I published an overview of the designer architecture. I’ll copy the picture and the description of what I want to talk about today.

There are a few key components here

Source

In VS, this is xaml, but this represents the durable storage of the “thing” we are editing

Instance

This is the in memory representation of the item being edited. In vs2010 for the WF designer, this is a hierarchy of System.Activities instances (an object tree)

Model Item Tree

This serves as an intermediary between the view and the instance, and is responsible for change notification and tracking things like undo state

Design View

This is the visual editing view that is surfaced to the user, the designers are written using WPF, which uses plain old data binding in order to wire up to the underlying model items (which represent the data being edited).

Metadata Store

This is a mapping between type and designers, an attribute table for lack of a better term. This is how we know what designer to use for what type

Motivating the ModelItem tree

One observation that you could make when looking at the diagram above is “I should just be able to bind the view to the instance.” This approach could work, but has a couple of implementation problems:

It is unrealistic to expect that instances of runtime types will all be built to fit perfectly into a design oriented world. The most obvious problem is that our activity types aren’t going to inherit from DependencyObject, or implement INotifyPropertyChanged. We can’t specify that all collections are ObservableCollection [interesting trivia, ObservableCollection has moved from WindowsBase.dll into System.dll]. If we could, that would make life easy, but that’s not the case.
- Additionally, there are design time services that we need to think about supporting (such as Undo/Redo), and we need to make sure we can consistently handle this across many object types, including those that have not been written by us.
There may be a case for not actually operating on a live instance of the object graph. Note, in VS2010, we do, but if we want to do work that would enable a design time XAML experience, we would need our instance to actually contain a lot of information about the source document.
If we go directly from the view to the instance, we tightly couple the two together, and that makes doing more interesting things in the future tricky. For instance, if we want to add refactoring support to update instances of objects, we need more than just the object graph to do that (the model item tree also keeps track of things like back pointers, so I know everybody that references the object).

These reasons cause us to think about an abstraction we can use to intermediate the implementation details of the instance and the view with a common layer. If you have programmed at the WPF designer extensibility level, you will likely be familiar with the idea (and some of the types) here.

The ModelItem tree

The way that I think about the ModelItem/ModelProperty tree is that it forms a very thing proxy layer on top of the shape of the instance being edited.

Let’s start with a very simple type:

public class Animal
{
    // simple property
    public string Name { get; set; }
    // complex property 
    public Location Residence { get; set; } 
    // list 
    public List<Animal> CloseRelatives { get; set; }
    // dictionary
    public Dictionary<string, object> Features { get; set; } 
}

public class Location
{
    public string StreetAddress { get; set; }
    public string City { get; set; }
    public string State { get; set; } 
}

Ignore for a moment that I just gave an animal Features, I’m a PM, it’s how we think :-)

Now, let’s create some instances of that, and then actually create a ModelItem.

   1:  EditingContext ec = new EditingContext();

   2:  var companion1 = new Animal { Name = "Houdini the parakeet" };

   3:  var companion2 = new Animal { Name = "Groucho the fish" };

   4:  var animal = new Animal

   5:                   {

   6:                       Name = "Sasha the pug",

   7:                       Residence = new Location

   8:                       {

   9:                           StreetAddress = "123 Main Street",

  10:                           City = "AnyTown",

  11:                           State = "Washington"

  12:                       },

  13:                       Features = {

  14:                          {"noise", "snort" },

  15:                          {"MeanTimeUntilNaps", TimeSpan.FromMinutes(15) }

  16:                       },

  17:                       CloseRelatives = { companion1, companion2 }

  18:                   };

  19:  ModelTreeManager mtm = new ModelTreeManager(ec);  mtm.Load(animal);

  20:  ModelItem mi = mtm.Root;

One thing to note here is that I am using ModelTreeManager and EditingContext outside the context (no pun intended) of the designer (see lines 1, 19, and 20 in the above snippet). This isn’t the usual way we interact with these, but it’s for this sample so that we can focus just on the data structure itself. [as an aside, my brother did have a parakeet named Houdini].

Let’s take a quick look at a visualization of what the data structure will look like. Remember to think about the ModelItem tree as a thin proxy to the shape of the instance.

Rather than spend an hour in powerpoint, I’ll just include a sketch :-)

On the left, you see the object itself. For that object, there will be one ModelItem which “points” to that object. You can call ModelItem.GetCurrentValue() and that will return the actual object. If you look at the ModelItem type, you will see some interesting properties which describe the object.

ItemType is the type of the object pointed to (in this case, Animal)
Parent is the item in the tree which “owns” this model item (in the case of the root, this is null)
Source is the property that provided the value (in the case of the root, this is null)
Sources is a collection of all the backpointers to all of the properties which hold this value
- Note, the distinction between Source and Sources and Parent and Parents is a topic worthy of another post
View is the DependencyObject that is the visual (in teh case above, this is null as there is no view service hooked into the editing context)
Properties is the collection of properties of this object

Properties is the part where things get interesting. There is a collection of ModelProperty objects which correspond to the shape of the underlying objects. For the example above, let’s break in the debugger and see what there is to see.

As we might expect, there are 4 properties, and you will see all sorts of properties that describe the properties. A few interesting ones:

ComputedValue is a short circuit to the return the underlying object that is pointed to by the property. This is equivalent to ModelProperty.Value.GetCurrentValue(), but has an interesting side effect that setting it is equivalent to SetValue().
Name, not surprisingly, this is name of the property
PropertyType is the type of the property
Collection and Dictionary are interesting little shortcuts that we’ll learn about in a future blog post.
Value points to a model item that is in turn the pointer to the value
Parent points to the ModelItem which “owns” this property

As Value points to another model item, you can see how this begins to wrap the object, and how this can be used to program against the data model. Let’s look at a little bit of code.

root.Properties["Residence"].
                Value.
                Properties["StreetAddress"].
                Value.GetCurrentValue()

You might say “hey, that’s a little ugly” and I have two bits of good news for you.

ModelItem has a custom type descriptor, which means that in WPF XAML we can bind in the way we expect (that is, I can bind to ModelItem.Location.StreetAddress, and the WPF binding mechanism will route that to mi.Properties[“Location”].Value.Properties[“StreetAddress”]. So, if you don’t use C# (and just use XAML), you don’t worry about this
In RTM, we will likely add support for the dynamic keyword in C# that will let you have a dynamic object and then program against it just like you would from WPF XAML. It’s pretty cool and I hope we get to it, if we do I will blog about it.

Here’s a set of tests which show the different things we’ve talked about:

   1:  ModelItem root = mtm.Root;

   2:  Assert.IsTrue(root.GetCurrentValue() == animal, "GetCurrentValue() returns same object");

   3:  Assert.IsTrue(root.ItemType == typeof(Animal),"ItemType describes the item");

   4:  Assert.IsTrue(root.Parent == null,"root parent is null");

   5:  Assert.IsTrue(root.Source == null, "root source is null");

   6:  Assert.IsTrue(((List<Animal>)root.Properties["CloseRelatives"].ComputedValue)[0] == companion1,

   7:             "ComputedValue of prop == actual object");

   8:  Assert.IsFalse(((List<Animal>)root.Properties["CloseRelatives"].ComputedValue)[0] == companion2,

   9:             "ComputedValue of prop == actual object");

  10:  Assert.AreEqual(root.Properties["Residence"].

  11:      Value.

  12:      Properties["StreetAddress"].

  13:      Value.GetCurrentValue(), "123 Main Street", "get actual value back out");

  14:  Assert.AreEqual(root, root.Properties["Residence"].Parent, "property points to owner");

  15:  ModelItem location = root.Properties["Residence"].Value;

  16:  Assert.AreEqual(root.Properties["Residence"], location.Source, "sources point to the right place");

Oh my, won’t this get explosively large?

Good question, and the truth is that yes, this could get large as you were to spelunk the object graph. The good news is that we’re incredibly lazy about loading this, we will only flush out the properties collection on demand, and we won’t generate a ModelItem until it is requested. When we combine this with the View virtualization work we have done, we will only ever load as much in the WF designer as you need. This keeps the overhead minimal, and in does not represent a substantial memory overhead.

Why should I be careful about ModelItem.GetCurrentValue()

One might be tempted to just say “Hey, I’m in C#, I’ll just call GetCurrentValue() and party on that. If you do that, you are entering dangerous waters where you can mess up the data model. Since the underlying instance doesn’t likely support any change notification mechanism, the model item tree will get out of sync with the underlying instance description. This will manifest itself in problems at the designer because our serialization is based off the instance, not the ModelItem tree (note, that’s a vs2010 implementation detail that could change in a subsequent release). The net result though is that you will get your view out of sync with your instance and serialization and that’s generally considered problematic.

Summary

Wow, that’s a longer post than I intended. What have we covered:

The Modelitem tree and why we need it
The relationship between the underlying instance and ModelItem/ModelProperty
The shape and use of ModelItem / ModelProperty
Imperative programming against the tree

What haven’t we covered yet

ModelItemCollection and ModelItemDictionary
How to use Sources and Parents to understand how the object sits in the graph and manipulation we can do for fun and profit

I’ll get there. In the meantime, if you have questions, let me know.

**** Minor update on 10/29 to fix a bug in the code ****

This is the way to use ModelTreeManager to generate ModelItems (Line 3 is the critical piece that was missing):

   1:  EditingContext ec = new EditingContext();

   2:  ModelTreeManager mtm = new ModelTreeManager(ec);

   3:  mtm.Load(new Sequence());

   4:  mtm.Root.Properties["Activities"].Collection.Add(new WriteLine());

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!

Matt W's Windows Workflow Place

Thoughts on Flowchart

Arbitrary Rework

Coordination

How’d we get to where we are today?

Where does this leave us?

Improving ModelItem with Dynamic

VS 2010 RC Is Available

Making Swiss Cheese Look Good, or Designers for ActivityAction in WF4

Swiss Cheese and WF4, or, An Introduction to ActivityAction

Motivation

Introducing ActivityAction

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

VS Standard Services and Items

Items

Services

Basic Rehosted Application Standard Services and Items

Items

Services

Comparison Table View

Conclusion

Subscription / Notification Engine (WF4 EditingContext Intro Part 5)

Services

Method

Description

Method

Description

Why is this Useful?

Items

Providing Callbacks for the Host (WF4 EditingContext Intro Part 4)

Host Provided Capabilities (WF4 EditingContext Intro Part 3)

Sharing Functionality Between Designers (WF4 EditingContext Intro Part 2)

Setup

What We Will See

Publishing a Service

Consuming a Service

Subscribing to Service

Before & After

What about Items?

Introduction to the WF4 Designer Editing Context (Part 1)

Motivation

Items

Services

Emitting the mc:Ignorable Instruction In Your WF4 XAML

Why use mc:Ignorable?

Why do I have to worry about this?

How Do I Get the Same Behavior?

AttachedProperty Part 2, Putting it Together

Pulling it all Together

WF4 Design Time AttachedPropertiesService and Attached Properties

Motivation

How Does it Work

Getter/ Setter?

Looking at Some Code

What do I do now?

Full Code Posting

WF4 ViewStateService

Motivation

Where to write them down?

How do we use it?

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

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

WF4, WCF and AppFabric Sessions @ PDC09

WF Talks

WCF Talks

AppFabric Talks

A Few Additional Treats @ PDC09

Matt’s PDC Session List

Session Name

Comment

Displaying Validation Errors in a Rehosted WF4 Designer

“I’d like to find out if the workflow in the designer is valid… is there someway to retrieve the validation errors?”

Got a cool .NET app? Hang with Tortoises for 12 days

Finding the Variables in Scope Within the WF Designer

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

Current Approach

Potential Future Approach

WF4 Beta1 => Beta2 Breaking Changes Document Published

Deep Dive into the WF4 Designer Data Model: ModelItem and ModelProperty

Motivating the ModelItem tree