Matt W's Windows Workflow Place : beta

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.

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.

Types, Metatypes and Bears, Redux

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

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

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

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

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

What’s New

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

What’s Changed

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

ActivityXamlServices Members

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

Creates an instance of an activity tree described in XAML.

The ActivityXamlServices type exposes the following members.

Methods

Name

Description

CreateBuilderReader

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

CreateBuilderWriter

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

CreateReader

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

Load

Overloaded. Creates an instance of a declarative workflow.

Top

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

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

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

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

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

Here is some sample code that walks through this:

   1:  ActivityBuilder ab1 = new ActivityBuilder();

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

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

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

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

   6:  ab1.Implementation = new Sequence

   7:  {

   8:      Activities =

   9:      {

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

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

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

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

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

  15:      }

16:

  17:  };

  18:  StringBuilder sb = new StringBuilder();

  19:  StringWriter tw = new StringWriter(sb);

  20:  XamlWriter xw = ActivityXamlServices.CreateBuilderWriter(

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

  22:  XamlServices.Save(xw , ab1);

  23:  string serializedAB = sb.ToString();

24:

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

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

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

28:

29:

  30:  ActivityBuilder ab = XamlServices.Load(

  31:      ActivityXamlServices.CreateBuilderReader(

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

33:

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

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

  36:  Console.ReadLine();

Good luck, and happy metatyping!

Navigating the WF4 Beta 2 Samples

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

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

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

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

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

Basic

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

\WF\Basic

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

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

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

Scenario

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

Application

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

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

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

Extensibility

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

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

WF4 Designer Enhancements in VS 2010 Beta 2

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

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

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

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

New UI

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

We’ve rounded out the set of icons as well

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

Expand in Place

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

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

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

Choose Toolbox Items

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

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

Imports Designer

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

Before:

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

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

Text on Flowchart Labels

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

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

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

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

Switch will display the switch values as well.

IActivityTemplateFactory is Public

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

   1:  public sealed class PickWithTwoBranchesFactory : IActivityTemplateFactory

   2:  {

   3:      public Activity Create(DependencyObject target)

   4:      {

   5:          return new Pick

   6:          {

   7:              Branches =

   8:              {

   9:                  new PickBranch

  10:                  {

  11:                      DisplayName = "Branch1"

  12:                  },

  13:                  new PickBranch

  14:                  {

  15:                      DisplayName = "Branch2"

  16:                  }

  17:              }

  18:          };

  19:      }

  20:  }

Namespace change

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

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

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

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

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

Writeline Designer

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

UI Virtualization

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

Information About Arguments in the Property Grid

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

   1:  public sealed class MySimpleActivity : CodeActivity

   2:  {

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

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

5:

   6:      protected override void Execute(CodeActivityContext context)

   7:      { ...

will show up like this in the property grid:

Bonus Feature: Additional Toolbox Organization

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

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

Introducing the WF4 Designer

mwinkle — Wed, 20 May 2009 23:27:51 GMT

// standard disclaimer applies, this is based on the released Beta 1 bits, things are subject to change, if you are reading this in 2012, things may be, look, smell, work differently. That said, if it’s 2012 and you’re reading this, drop me a line and let me know how you found this!

As you might have heard, Beta1 of VS is out the door, and available to the public sometime today. As you may know we’ve done a bunch of work for WF4, and I wanted to give a quick, high level overview of the designer. Here’s a good overview for the new WF bits all up.

First, let’s start with your existing WF projects. What happens if I want to create a 3.5 workflow? We’re still shipping that designer, in fact, let’s start there on our tour. This shows of a feature of VS that’s pretty cool, multitargeting.

Click New Project

Notice the “Framework Version” dropdown in the upper right hand corner.

This tells VS which version of the framework you would like the project you are creating to target. This means you can still work on your existing projects in VS 2010 without upgrading your app to the new framework. Let’s pick something that’s not 4.0, namely 3.5. You’ll note that the templates may have updated a bit, select Workflow from the left hand tree view and see what shows up.

There isn’t anything magical about what happens next, you will now see the 3.5 designer inside of VS2010. You’re able to build, create, edit and update your existing WF applications.

Let’s move on and switch over to a 4.0 workflow.

Create a new project and select 4.0

Create a new WF Sequential Console application and name it “SampleProject”. Click Ok.

We’ll do a little bit of work here, but you will shortly see the WF 4.0 designer. It looks a little different from the 3.x days, we’ve taken this time to update the designer pretty substantially. We’ve built it on top of WPF, which opens up the doors for us to do a lot of interesting things. If you were at PDC and saw any Quadrant demos, you might think that these look similar. We haven’t locked on the final look and feel yet, so expect to see some additional changes there, but submit your feedback early and often, we want to know what you think.

Let’s drop some activities into our sequence and see what’s there to be seen.

We’ve categorized the toolbox into functional groupings for the key activities. We heard a lot of feedback that it was tough to know what to use when, so we wanted to provide a little more help with some richer default categories. Add an Assign activity, a WriteLine activity and a Delay activity to the canvas by clicking and dragging over the to the sequence designer.

You’ll note that we’ve now got some icons on each activity indicating something is not correct. This is a result of the validation executing and returning details about what is wrong. Think of these as the little red squiggles that show up when you spell something wrong. You can hover over the icon to see what’s wrong

You can also see that errors will bubble up to their container, so hovering over sequence will tell you that there is a problem with the child activities.

What if I have a big workflow, and what if I want to see a more detailed listing of errors? Open up the Error View and you will see the validation results are also displayed here. You’ll note there is some minor formatting weirdness. This is a bug that we fixed but not in time for the Beta1 release.

Now, let’s actually wire up some data to this workflow. WF4 has done a lot of work to be much more crisp about the way we think about data within the execution environment of a workflow. We divide the world into two types of data, Arguments, and Variables. If you mentally map these to the way you write a method in code (parameters, and state internal to the method), you are one the right track. Arguments determine the shape of an activity, what goes in, what goes out. Variables allocate storage within the context of an activities execution. The neat thing about variables, once the containing activity is done, we can get rid of the variables, as our workflow no longer needs them (note, we pass the important data in and out through the arguments). To do this, we have two special designers on the canvas that contain information about the arguments and variables in your workflow

First, let’s click on the Argument designer and pass in some data.

Arguments consist of a few important elements

Name
Type
Direction
Default Value (Optional)

Most of these are self explanatory, with the one exception being the Direction. You’ll note that this has In, Out and Property. Now, when you are editing the arguments, you are actually editing the properties of the underlying type you are creating (I’ll explain more about this in a future post). A more appropriate name might be “Property Editor” but the vast majority of what you’ll be creating with it is arguments. Anyway, If you select In or Out, this basically wraps the type T in an InArgument, so it becomes a property of type InArgument<T>. We just provide a bit of a shorthand so you don’t always have to pick InArgument as the type. The default value takes an expression, but in this case, we won’t be using it.

Let’s go ahead and add an argument of type TimeSpan named DelayTime. You’ll need to select browse for types and then search for the TimeSpan

Variables are similar, but slightly different, variables have a few important elements:

Name
Type
Scope
Default Value (Optional)

Remember earlier, I mentioned that variable is part of an activity, this is what Scope refers to. Variables will only show up to be the scope of the selected activity, so if you don’t see any, make sure to select the Sequence, and then you will be able to add a variable. Let’s add new variable, named StringToPrint, of type String.

Now let’s do something with these in the workflow. One thing I’m particularly happy with that we’ve done on the designer side of things is to enable people to build activity designers more easily. There are lots of times where you have activities that have just a few key properties that need to be set, and you’d like to be able to see that “at a glance” The assign designer is like that.

Now, let’s dig into expressions. One big piece of feedback from 3.0 was that people really wanted richer binding experiences. You see this as well with the WPF data binding . We’ve taken it to the next level, and allow any expression to be expressed as a set of activities. What this means is that we do have to “compile” textual expressions into a tree of activities, and this is one of the reasons we use VB to build expressions. In the fullness of time, other languages will come on board. But how to use it, let’s see. Click on the “To” text box on the Assign activity. You will see a brief change of the text box, and then you will be in a VB Expression Editor, or what we’ve come to refer to as “The Expression Text Box” or ETB. Start typing S, and already you will see intellisense begin to scope down the choices. This will pick up all of the variables and arguments in scope.

On the right side, we won’t use any of the passed in arguments, we’ll show off a richer expression. Now, the space on the right side of the designer is kind of tight for something lengthy, so go to the property grid and click on the “…” button for the Value property

String.Format("Someone wants to wait {0} seconds", TimeToWait.TotalSeconds)

This just touches the surface of what is possible with expressions in WF4, we can really get much richer expressions (3.x expressions are similar to WPF data binding, they are really an “object” + “target” structure).

Not everything makes it to the canvas of the designer surface, and for that, we have the property grid. If you’ve used the WPF designer in VS2008, this should look pretty familiar to you. Select the delay activity, and use the property grid to set the duration property to the InArgument you created above. This experience is similar, with the ETB embedded into the property grid for arguments.

Finally, repeat with the WriteLine and bind to the StringToPrint variable.

Navigating the Workflow

There are two different things that we have to help navigating the workflow, our breadcrumb bar at the top and the overview map (which appears as the “Mini Map” in the beta). Let’s look at the overview map. This gives you a view of the entire workflow and the ability to quickly scrub and scroll across it.

Finally, across the top we display our breadcrumbs which are useful when you have a highly nested workflow. Double click on one of the activities, and you should see the designer “drill into” that activity. Now notice the breadcrumb bar, it displays where you have been, and by clicking you can navigate back up the hierarchy. In beta1, we have a pretty aggressive breadcrumb behavior, and so you see “collapsed in place” as the default for many of our designers. We’re probably going to relax that a bit in upcoming milestones to reduce clicking and provide a better overview of the workflow.

Finally, there may be times where we don’t want to have a designer view, but would rather see the XAML. To get there, just right click on the file and ask to “View Code”

This will currently ask you if you are sure that you want to close the designer, and you will then see the XAML displayed in the XML editor. For the workflow we just created, this is what it looks like:

   1:  <p:Activity mc:Ignorable=""

   2:       x:Class="WorkflowConsoleApplication1.Sequence1"

   3:       xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities/design"

   4:       xmlns:__Sequence1="clr-namespace:WorkflowConsoleApplication1;"

   5:       xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

   6:       xmlns:p="http://schemas.microsoft.com/netfx/2009/xaml/activities"

   7:       xmlns:s="clr-namespace:System;assembly=mscorlib"

   8:       xmlns:sad="clr-namespace:System.Activities.Debugger;assembly=System.Activities"

   9:       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

  10:    <x:Members>

  11:      <x:Property Name="TimeToWait" Type="p:InArgument(s:TimeSpan)" />

  12:    </x:Members>

  13:    <__Sequence1:Sequence1.TimeToWait>

  14:      <p:InArgument x:TypeArguments="s:TimeSpan">[TimeSpan.FromSeconds(10)]</p:InArgument>

  15:    </__Sequence1:Sequence1.TimeToWait>

  16:    <p:Sequence>

  17:      <p:Sequence.Variables>

  18:        <p:Variable x:TypeArguments="x:String" Name="StringToPrint" />

  19:      </p:Sequence.Variables>

  20:      <p:Assign>

  21:        <p:Assign.To>

  22:          <p:OutArgument x:TypeArguments="x:String">

  23:              [StringToPrint]

  24:          </p:OutArgument>

  25:        </p:Assign.To>

  26:        <p:Assign.Value>

  27:          <p:InArgument x:TypeArguments="x:String">

  28:                    [String.Format("Someone wants to wait {0} seconds", TimeToWait.TotalSeconds)]

  29:           </p:InArgument>

  30:        </p:Assign.Value>

  31:      </p:Assign>

  32:      <p:Delay>[TimeToWait]</p:Delay>

  33:      <p:WriteLine>[StringToPrint]</p:WriteLine>

  34:    </p:Sequence>

  35:  </p:Activity>

Executing the Workflow

Inside the project you will see the Program.cs to execute the workflow, let’s take a look at that.

   1:  namespace WorkflowConsoleApplication1

   2:  {

   3:      using System;

   4:      using System.Linq;

   5:      using System.Threading;

   6:      using System.Activities;

   7:      using System.Activities.Statements;

   8:      using System.Collections.Generic;

9:

  10:      class Program

  11:      {

  12:          static void Main(string[] args)

  13:          {

  14:              AutoResetEvent syncEvent = new AutoResetEvent(false);

15:

  16:              WorkflowInstance myInstance =

  17:                  new WorkflowInstance(new Sequence1(),

  18:                      new Dictionary<string, object>

  19:                      {

  20:                          {"TimeToWait", TimeSpan.FromSeconds(3.5) }

  21:                      }

22:

23:

24:

  25:                      );

  26:              myInstance.OnCompleted = delegate(WorkflowCompletedEventArgs e) { syncEvent.Set(); };

  27:              myInstance.OnUnhandledException = delegate(WorkflowUnhandledExceptionEventArgs e)

  28:              {

  29:                  Console.WriteLine(e.UnhandledException.ToString());

  30:                  return UnhandledExceptionAction.Terminate;

  31:              };

  32:              myInstance.OnAborted = delegate(WorkflowAbortedEventArgs e)

  33:              {

  34:                  Console.WriteLine(e.Reason);

  35:                  syncEvent.Set();

  36:              };

37:

  38:              myInstance.Run();

39:

  40:              syncEvent.WaitOne();

  41:              Console.WriteLine("Press <Enter> to exit");

  42:              Console.ReadLine();

43:

  44:          }

  45:      }

  46:  }

This is the standard program.cs template with two modifications. The first is passing data into the workflow, indicated by the dictionary we create to pass into the WorkflowInstance. This should look familiar if you have used WF in the past.

 WorkflowInstance myInstance =
                new WorkflowInstance(new Sequence1(),
                    new Dictionary<string, object>
                    {
                        {"TimeToWait", TimeSpan.FromSeconds(3.5) }
                    }
                 );

The second is a break at the end to keep our console window open (lines 41 and 42). Hitting F5 from our project results in the following output (as expected).

This concludes our brief tour through the new WF designer. I’ll be talking a lot more in upcoming days about some of the more programmatic aspects of it and how it’s put together.

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