Most of the time you will author new activities and workflows using the workflow designer that is integrated into Visual Studio. However, you may need to enable end users of your application to also design activities and workflows. You can allow them to load and customize existing Xaml files or to create new ones.

The workflow designer is not limited to use only within the Visual Studio environment. WF provides the classes necessary to host this same designer within your applications. This chapter is all about hosting this designer. After a brief overview of the major workflow designer components, you will implement a simple application that hosts the workflow designer. In subsequent sections, you will build upon the application, adding new functionality with each section.

Understanding the Workflow Designer Components

The workflow designer functionality is provided in a set of classes that is located in the System.Activities.Presentation namespace and its associated child namespaces. Here are the additional child namespaces that you are likely to use when you host the designer:

The workflow designer is architected in layers, with components in each layer interacting with those above or beneath it. It might be helpful to keep these layers in mind as you explore the classes that you will use to host the designer.

• Visual: This includes the visual controls that a developer uses to interact with the activity definition. The visual components interact with the ModeItem tree.
• ModelItem tree: This is a tree of ModelItem objects that sit between the visual elements and the in-memory representation of the activity definition. They track changes to the underlying definition.
• Activity definition: This is the in-memory tree of activities that have been defined.
• MetadataStore: An in-memory store of attributes that is used to associate activities with their designers.

In the sections that follow, I review the most important classes that you are likely to encounter when you develop your own designer host application.

Understanding the WorkflowDesigner Class

To host the workflow designer, you create an instance of the WorkflowDesigner class. Here are the most important members of this class:

After creating the WorkflowDesigner instance, you add the control referenced by the View property to a WPF window in order to display the designer canvas. This property is a UIElement, which is a WPF control that can be placed directly on a window or within another control. In a like manner, the PropertyInspectorView property references a WPF control that you can also add to your WPF application. It provides the property grid, which allows you to change property values for the currently selected activity in the designer. The two controls are automatically linked, so there’s no need for additional code to set the current selection for the property grid.

To initialize the designer with a definition, you use one of the overloads of the Load method. One overload of this method allows you to specify the file name of the Xaml file containing the definition. With another overload, you pass an object that represents the definition. This object could be a single activity or an entire tree of activities that you constructed in code. You can also set the Text property to the Xaml string representing the definition and then invoke the Load method without any parameters. This last option is useful if you are persisting the definition in a database or another medium instead of directly in the file system.

To save the current definition, you can invoke the Save method, passing the name of the file to use when saving. But that method is useful only if you are saving the definition directly to the file system. You can also retrieve the Xaml string from the Text property and save it yourself (to the file system, to a database, and so on).

Understanding the ToolboxControl

The WorkflowDesigner class provides the designer canvas and a coordinated properties grid. It doesn’t automatically provide a Toolbox containing the activities that can be dropped onto the canvas. However, WF does provide these classes that allow you to easily construct your own Toolbox:

• ToolboxControl: A WPF UIElement that visually represents the Toolbox
• ToolboxCategory: Defines a single activity category in the Toolbox
• ToolboxItemWrapper: Defines a single tool entry in the Toolbox

These classes are located in the System.Activities.Presentation.Toolbox namespace. To create a Toolbox, you first create an instance of the ToolboxControl and add it to the WPF window. You then create the categories and individual items that you want to show in the Toolbox. Since you are implementing your own designer host application, you have complete freedom as to the set of activities that you show, as well as how you organize them into categories. You don’t have to include all of the standard activities or use the standard categories.

Each Toolbox category is represented by an instance of the ToolboxCategory class. After creating a new instance, you use the Add method of this class to add the individual items in that category. Each item is represented by an instance of the ToolboxItemWrapper class. Several constructor overloads are provided for this class, allowing you to specify varying degrees of information for each tool.

You must provide the type of the item and a display name. The item type is the type of Activity that you want to add when someone drags this tool to a workflow definition. You can optionally specify a bitmap file name if you want to customize the image that is shown for the item in the Toolbox.

Defining New Activities

To use the workflow designer, it must always have a root object. Loading an existing Xaml definition satisfies this requirement since the definition contains one or more activities with a single root activity.

But what do you load into the designer if you want to create a new activity? The answer to this question is not as obvious as you might think. You might look at a Xaml file and notice that the root is the Activity element. So, your first attempt might be to create an instance of an empty Activity class and load that into the designer. The problem is that the Activity class is abstract and doesn’t have a public constructor. The same applies to frequently used child classes like CodeActivity and NativeActivity. You can create an instance of other activities, such as the Sequence class, and load them directly into the designer. But then every new activity that you design has the Sequence activity as its root. And the Sequence activity supports the entry of variables but doesn’t support any way to define arguments.

To solve this problem, you need to load an instance of a special class named ActivityBuilder (found in the System.Activities namespace). This class is designed for the sole purpose of defining new activities. When loaded into the designer, this class provides an empty canvas, waiting for you to add your chosen root activity. It also supports the definition of arguments. Here are the most important properties of this class:

I said that this class supports the definition of arguments, but from the list of supported properties, it may not be obvious where they are defined. Arguments are maintained in the Properties collection as DynamicActivityProperty instances. You will use this property later in the chapter to display a list of defined arguments.

Understanding the EditingContext

The WorkflowDesigner supports a Context property that is an instance of the EditingContext class. This object is your interface to the current internal state of the designer. It allows you to access state that is shared between the designer and the host application. For example, you can use the Context property to identify the activity that is currently selected in the designer. It also provides access to services that have been loaded into the designer. These services provide functionality that is shared between the designer and the host application or by individual activity designers. Here are the most important properties of this class:

Context.Items

The ContextItemManager (the Context.Items property) provides access to individual objects that derive from the base ContextItem class. Here are the most important members of this class:

Each object in the Context.Items collection serves a different purpose and maintains a different type of shared state. Here are the standard objects that are available—you won’t necessarily need to access all of these objects in a typical designer application:

Context.Services

The Context.Services property is an instance of a ServiceManager object. This object provides access to a set of standard services that are automatically loaded when you create an instance of the designer. As you will see later in the chapter, you can also add your own custom services to provide optional functionality. The ServiceManager class provides these members:

Here are some of the standard services that are available when you self-host the designer:

Providing Designer Metadata

As you learned in Chapter 15, there are two ways to associate a designer with a particular activity:

• You can apply the Designer attribute directly to the activity.
• You can use the MetadataStore class at runtime.

If you opted for the second option when you implemented your custom activities and designers, you need to use the MetadataStore class to associate each activity with its designer. If you are using the standard WF activities (this is very likely), you also need to use the DesignerMetadata class (located in the System.Activities.Core.Presentation namespace). This class supports a single Register method that associates each standard WF activity with its designer. You only need to invoke this method once during the lifetime of your application.

You can also use the MetadataStore class to associate custom designers with the standard activities. Providing your own metadata entries overrides the defaults that are provided when you invoke the DesignerMetadata.Register method.

The Self-hosting Designer Workflow

If you are developing an application to host the workflow designer, you obviously need to create or maintain activity definitions outside Visual Studio. And your application will be designed to satisfy the particular requirements of your end users. That means your application will likely look much different from the one that I might implement (or the one that is presented in the remainder of this chapter). But in general, you might want to consider these steps when you decide to self-host the workflow designer:

1. Design a WPF application that can support the designer visual components.
2. Create an instance of the WorkflowDesigner class and add the object referenced by the View property to a WPF window to display the main designer canvas.
3. Add the object referenced by the PropertyInspectorView property to a WPF window to provide property grid functionality.
4. Register metadata for the standard and custom activities.
5. Create and manage a Toolbox containing activities that can be dropped onto the designer canvas.
6. Add logic to initialize a new activity definition. Also add logic to save and load activity definitions to a file or other persistence medium.
7. Add logic to react to the currently selected item by providing context menus, context Toolbox support, and so on.
8. Provide custom validation logic and display validation errors.

Implementing a Simple Workflow Designer

In the remainder of this chapter, you will implement a WPF application that hosts the workflow designer. The example application will begin with minimal functionality that will be enhanced in the sections that follow this one. Each section builds upon the code that was developed in the previous section.

Creating the Application

Create a new project using the WPF Application project template. Name the project DesignerHost, and add it to a new solution that is named for this chapter. Add these assembly references to the project:

• System.Activities
• System.Activities.Presentation
• System.Activities.Core.Presentation

All the components and code that you will add to this application will go into the MainWindow class that was added by the new project template. The MainWindow.xaml file contains the WPF markup for the window, and the MainWindow.xaml.cs file contains the C# code.

Declaring the Window Layout

Before you can implement any code for the application, you need to lay out the controls of the MainWindow class. Double-click the MainWindow.xaml file in the Solution Explorer to open it in Design View. Design View in this case is a split screen that includes a WPF designer and an XML editor showing the Xaml markup. Here is the complete markup that you need to add to this file:

I’ve included a handler for the Closing event of the window (shown in the previous code). You will add code to this handler to test for any unsaved changes to the current definition. The window is organized into three columns and three rows. The leftmost column will be used for a Toolbox of activities, and the rightmost column is for the properties grid. The middle column is reserved for the workflow designer canvas. The first row is used for a menu, while the second row is the main area for the designer, Toolbox, and properties grid. The third row is reserved for a message area.

A menu is defined that allows the user to select the main operations of the application. Handlers are defined for all the menu items, so you’ll need to include code for these event handlers even though you won’t fully implement them immediately.

I’ve included a Border control as a placeholder for each of the three main designer areas. This provides a subtle visual separation between the controls and also simplifies the code that populates these areas with the designer controls. The markup also includes a ListBox control that occupies the final row (the message area).

The markup also includes GridSplitter controls between the three main sections. These controls allow you to drag the gray bar between the sections to resize the Toolbox or the properties grid.

The project won’t build at this point since the markup is referencing event handlers that you haven’t implemented. You’ll turn your attention to the code next.

Implementing the Application

Open the MainWindow class in Code View. This should open the MainWindow.xaml.cs file in the code editor. Here is the initial implementation of this class:

The code includes a number of namespaces that you won’t initially need. However, you will need them by the time you complete this chapter, so go ahead and include all of them now.

During construction of the window, the metadata for the standard activities is registered using the DesignerMetadata class. A Toolbox containing a subset of the standard activities is then constructed. Finally, an instance of the designer is initialized with a call to the private InitializeDesigner method, and a new empty workflow is loaded by calling the StartNewWorkflow method.

The InitializeDesigner method creates a new instance of the designer and wires it up to the designated areas on the window. An event handler is added to the ModelChanged event of the designer. This will notify you whenever any changes are made to the current definition. As you will see later in the code, the InitializeDesigner method is called each time you need to clear the designer and begin a new activity definition. It is not possible to actually clear the designer or load a new definition once one has already been loaded.

The StartNewWorklfow handles the task of preparing the designer with a new ActivityBuilder instance. Loading this object presents the user with a clean canvas that they can use to define their own activity.

The handlers for the Save, SaveAs, and Open menu items will be fully implemented later in the chapter. However, they must be defined as shown here in order to successfully build the project:

The Run and Add Reference menu item handlers will also be implemented later in the chapter. The Run handler will contain logic that allows you to execute the current definition using the WorkflowInvoker class. The Add Reference handler will be used to load additional activities from a referenced assembly.

The handler for the ModelChanged event simply updates the title to indicate that there are unsaved changes.

The CreateToolbox method creates a Toolbox containing a small subset of the standard activities. There’s nothing special about the activities that I’ve chosen. Once you’ve completed the examples in this chapter, feel free to change the list of activities that are loaded to your preferred set of activities.

Each set of activities is organized into a named category. Each defined category is then passed to the CreateToolboxCategory private method to construct a ToolboxCategory object. These categories are then added to an instance of the ToolboxControl.

You may notice that instead of adding the ForEach<T> activity, the code references a class named ForEachWithBodyFactory<T>. The ParallelForEach<T> activity has also been replaced with a different class name (ParallelForEachWithBodyFactory<T>). These are the classes that are actually included in the Visual Studio Toolbox. They are activity templates that add the primary activity (for example ForEach<T>) and also add an ActivityAction<T> as a child of the primary activity. The ActivityAction<T> is needed to provide access to the argument that represents each item in the collection.

The CreateToolboxCategory method is invoked to create a new ToolboxCategory instance. The code creates ToolboxItemWrapper instances for each activity that was defined for the category. The null value that is passed to the ToolboxItemWrapper constructor is where you would pass the file name of a bitmap to associate with the toolbox item. Since the code passes null, a default image will be shown.

Testing the Application

You should now be able to build the project and run it. Figure 17-1 shows the initial view of the DesignerHost project when it is first started. Feel free to give the designer a try by dropping a few activities onto the canvas.

Figure 17-1. Initial view of DesignerHost

With the relatively small amount of code that you added, the application already has these capabilities:

• A fully functional workflow designer canvas including expand and collapse, zoom controls, and so on
• An integrated, context-sensitive properties grid
• A functional custom Toolbox
• Add, delete, move, cut, copy, and paste activities
• The ability to set property values including expressions
• The ability to validate the definition and highlight errors
• The ability to add variables and arguments
• The ability to clear the designer and start a new definition (the New menu option)

Figure 17-2 shows the designer after I added Sequence, Assign, and WriteLine activities. To enter the expressions for the Assign properties, I first added an Int32 variable named count that is scoped by the Sequence activity.

Figure 17-2. DesignerHost with activities

Executing the Workflow

In this section, you will enhance the application to support the execution of the current workflow definition. This allows the user to declare a workflow and immediately execute it as a preliminary test.

Modifying the Application

To add this functionality, you need to provide an implementation for the menuRun_Click event handler. Here is the code that you need to add to this method:

The code first calls the Flush method on the WorkflowDesigner object. Doing this ensures that the WorkflowDesigner.Text property contains Xaml that includes all of the most recent changes to the definition. The ActivityXamlServices class is used to deserialize the Xaml into a DynamicActivity instance that can be passed to the WorkflowInvoker class for execution.

Prior to execution, the standard Console is routed to a StringWriter. This allows the code to intercept and display the results that would normally go to the console.

Testing the Application

You can now rebuild and run the DesignerHost project. You can perform a preliminary test by just dropping a WriteLine activity onto the canvas and setting the Text property to a string of your choosing. If you select the Run option from the menu, you should see the expected results.

To perform a slightly more ambitious test that also includes a variable and an argument, I declared a simple workflow using these steps:

1. Add a While activity.
2. Declare an Int32 variable named count that is scoped by the While activity.
3. Add an Int32 input argument named ArgMax. Set the default value of this argument to 5.
4. Set the While.Condition property to count < ArgMax.
5. Add a Sequence to the While.Body.
6. Add an Assign activity to the Sequence activity. Set the Assign.To property to count and the Assign.Value property to count + 1.
7. Add a WriteLine immediately below the Assign activity. Set the Text property to "Count is" + count.ToString().

Figure 17-3 shows the completed workflow definition. Figure 17-4 shows the results when I select the Run option from the menu.

Figure 17-3. About to run a workflow

Figure 17-4. Workflow results

Loading and Saving the Definition

The next enhancement you will make is to add support for loading and saving the definition. The Save and SaveAs menu options will be implemented to save the definition to a Xaml file. The Open menu option will allow you to locate an existing Xaml file and load it into the designer.

Modifying the Application

You will make changes to the event handlers for the Save, SaveAs, and Open menu items that were defined but originally did not contain any code. The code that you add to these handlers will invoke new private methods that perform the actual I/O operations. Here is the code that you need to add to the three event handlers:

Here are the new private methods that you need to add to the MainWindow class:

Testing the Application

You can now rebuild the project and run it. All of the existing functionality should work in the same way as it did previously. However, you should now be able to use the Save, SaveAs, and Open operations to save your work and load existing Xaml files.

Displaying Validation Errors

The design canvas displays red error indicators on any activity that has a validation error. This works well, but you might also want to list all validation errors in one place. You can accomplish this by developing a custom service that implements the IValidationErrorService interface.

This interface (found in the System.Activities.Presentation.Validation namespace) defines a single ShowValidationErrors method that you must implement in your class. This method is passed a list of ValidationErrorInfo objects. Each object is an error or warning that has been detected. Once your custom service is registered with the EditingContext, the ShowValidationErrors method will be invoked to notify you of any errors or warnings.

Implementing the ValidationErrorService

Add a new C# class to the DesignerHost project, and name it ValidationErrorService. The plan is to display any validation errors and warnings in the ListBox that were added to the bottom of the window. To accomplish this, the constructor of this class is passed a reference to this ListBox. Here is the complete code that you need for this class:

Modifying the Application

To use the new service in the DesignerHost application, you first need to add a member variable for the service to the top of the MainWindow class like this:

Next, create a new instance of this service in the constructor of the MainWindow class. This must be done before the call to the InitializeDesigner method as shown here:

Finally, you need to add code to the InitializeDesigner method to publish this new service to the EditingContext of the designer. Calling the Publish method makes this new service available to the designer. You can add the call to the Publish method to the end of the InitializeDesigner method as shown here:

Testing the Application

Rebuild the project and run it to test the new functionality. To see the new service in action, you simply need to add an activity and generate a validation error. For example, you can add a Sequence activity and an Assign activity as its child. Since the Assign.To and Assign.Value properties require values, this should immediately generate the errors that are shown at the bottom of Figure 17-5. Correcting any validation errors clears the ListBox.

Figure 17-5. Workflow with validation errors

Adding Activities to the Toolbox

The designer application currently supports a subset of the standard activities in the Toolbox. In this section, you will enhance the application to support additional activities. You will add code to the Add Reference menu item handler that allows the user to select an assembly containing additional activities. Any activities that are found in the assembly are added to the Toolbox, making them available for use in the designer.

Additionally, you will enhance the code that loads an existing Xaml file to look for any activities that are not already in the Toolbox. Any new activities will be added to a new category and shown at the top of the Toolbox. This provides the user with access to any activities that are already in use in the loaded definition.

Modifying the Application

Begin by declaring two new member variables at the top of the MainWindow class. The autoAddedCategory will be reused each time a Xaml file is loaded to support any new activities that are found in the definition. The referencedCategories dictionary will be used to track the Toolbox categories for any assemblies that are manually referenced.

Next, add code to the StartNewWorkflow method to call a new private method. You will implement this new method later in the code. This new method will remove the Toolbox category that contains automatically added activities.

Modify the event handler for the Open menu item (menuOpen_Click) to call a new method named AutoAddActivitiesToToolbox. This method will inspect the newly loaded definition looking for activities that are not already in the Toolbox. The call to this method should be added after the designer has been initialized with the new definition. I’ve included the entire method to show you the context of where this line should be added:

You need to provide an implementation for the Add Reference menu item handler that was previously empty:

Finally, you need to add these new private methods to the MainWindow class. The AutoAddActivitiesToToolbox method finds any activities in the newly loaded definition that are not already in the Toolbox. There are two namespaces that are ignored during this process. If a new activity is found but is in one of these namespaces, it is not added to the Toolbox. These are the namespaces that are used for expression support, and you generally don’t want to add these activities to the Toolbox.

The AddReferencedActivitiesToToolbox method loads the specified assembly and looks for any activities. Any activities that are found are added to a new Toolbox category that is named for the assembly.

Testing the Application

You should now be ready to rebuild the project and run it. To test the new functionality, you need one or more custom activities. You can use the custom activities that you developed in Chapter 16 for this purpose. Copy these assemblies that you implemented and built in Chapter 16 to the indebug folder of the DesignerHost project. This assumes that you are currently building for debug.

• ActivityLibrary.dll
• ActivityLibrary.Design.dll

Now use the Add Reference menu option of the designer application to add a reference to the ActivityLibrary.dll that you just copied. You need to reference the assembly that is in the same folder as the DesignerHost project; otherwise, .NET won’t be able to resolve the reference correctly. After adding the reference to the assembly, you should see a list of custom activities appear at the bottom of the Toolbox. This is shown in Figure 17-6 under the ActivityLibrary category.

Figure 17-6. Toolbox with custom activities

You should now be able to drag the custom activities to the canvas. For example, you can follow these steps to produce the workflow shown in Figure 17-7.

1. Add a MySequence activity to the empty workflow. Set the Condition property to True.
2. Add an OrderScope activity as a child of the MySequence activity. Set the OrderId property to 1.
3. Add an OrderAddItems activity as a child of the OrderScope. Set the Items property to new System.Collections.Generic.List (Of Int32) From {1, 2, 3}.
4. Save the workflow definition to a file named CustomActivityTest.xaml. You are saving the definition so you can load it to test the automatic activity detection that occurs when loading an existing definition.

Figure 17-7. Workflow using custom activities

To test the automatic activity detection, close and restart the DesignerHost project. Doing so ensures that any custom activities that were previously loaded are now cleared. Now open the workflow file that you previously saved (CustomActivityTest.xaml). You should now see that the Auto category in the Toolbox has been populated with the custom activities that you referenced in the workflow, as shown in Figure 17-8.

Figure 17-8. Auto Toolbox category

Providing Designer Metadata

The DesignerHost application currently relies upon the standard activity designer metadata that was provided by the DesignerMetadata class. When you called the Register method of this class, the associations between the standard activities and their designers were added to the in-memory MetadataStore object.

In this section, you will modify the application to override the default designer for the While activity. In Chapter 16, you developed a custom MyWhile activity that just happens to match the signature of the standard While activity. You will now instruct the workflow designer to use the custom designer that you developed for this activity with the standard While activity.

The point of all of this is not to provide a better designer for the While activity. The standard designer for this activity works just fine. The point is to demonstrate how you can override the designer for any activity, even those that you didn’t author yourself. This demonstrates one of the key benefits of hosting the workflow designer yourself: you have much greater control over the design experience.

Referencing the Custom Designer

The custom designer that you will use is packaged in the ActivityLibrary.Design assembly that you developed in Chapter 16. You can update the DesignerHost project with a reference to this project in two ways. You can browse to this assembly (which should now be in your indebug folder) and add a direct assembly reference. Or, you can add the existing ActivityLibrary.Design and ActivityLibrary projects from Chapter 16 to your solution for this chapter and build them as part of the solution. You would then need to modify the DesignerHost project with a project reference to the ActivityLibrary.Design project.

Modifying the Application

To override the designer that is used for the While activity, you need to add this small amount of code to the end of the MainWindow constructor:

Testing the Application

Rebuild the solution, and run the DesignerHost project. Add a While activity to the empty designer canvas. You should see the custom designer that you developed in Chapter 16 instead of the standard designer, as shown in Figure 17-9. For your reference, Figure 17-3 shows the standard designer for the While activity.

Figure 17-9. While activity with custom designer

Tracking the Selected Activity

In many cases, you may need to know which activity is currently selected and make decisions based on that selection. In this section, you will enhance the DesignerHost application to adjust the Toolbox based on the currently selected activity.

The current code includes the three flowchart-related activities in the list of standard activities that are added to the Toolbox. However, the FlowDecision and FlowSwitch<T> make sense only if the currently selected activity is a Flowchart activity. These two activities can be added directly to a Flowchart activity only. The code that you will add in this section adds or removes the Toolbox items for the FlowDecision and FlowSwitch<T> activities depending on the currently selected activity in the designer.

Modifying the Application

First, add the declaration for these new member variables to the top of the MainWindow class:

Add new code to the end of the InitializeDesigner method. The new code adds a subscription to the Selection object in the EditingContext. Each time this object changes, the private OnItemSelected method will be executed.

Add the new OnItemSelected method. This method determines whether the currently selected activity is a Flowchart. If it is, the other flowchart-related activities are added to the flowchart category of the Toolbox. If the selection is not a Flowchart activity, the activities are removed from the category.

You also need to add code to the existing CreateToolbox method. The new code saves the flowchart category and the FlowDecision and FlowSwitch<T> Toolbox items in the new member variables. This allows the code in the OnItemSelected method (shown previously) to easily modify the category object.

Testing the Application

Rebuild and run the DesignerHost project. To test the new functionality, add a Flowchart as the root of the workflow. All the flowchart-related activities are shown in the Toolbox. Now add a WriteLine to the Flowchart you just added. Notice that when the WriteLine activity is selected, the FlowDecision and FlowSwitch<T> activities are removed from the Toolbox, as shown in Figure 17-10.

Figure 17-10. Flowchart with context-sensitive Toolbox

If you select the root Flowchart activity, all the flowchart-related activities are added back to the Toolbox.

Modifying the Context Menu

Since the application is now capable of reacting to the currently selected activity, it makes sense to enhance the context menu. The goal of the changes that you are about to make is to add a new context menu item when a Flowchart activity is selected. The new context menu will allow the user to add a FlowDecision activity to the Flowchart. When any other type of activity is selected, the context menu item will be removed. These changes also demonstrate how you can programmatically add activities to the model.

Modifying the Application

Begin this set of changes by adding a new member variable to the top of the MainWindow class, as shown here:

Next, modify the MainWindow constructor to call a new CreateContextMenu method. This call should be done before the call to the InitializeDesigner method, as shown here:

Modify the OnItemSelected method that you recently added. If the selected activity is a Flowchart, the code adds the new context menu item to the ContextMenu property of the WorkflowDesigner. If any other activity type has been selected, the context menu item is removed. I’ve highlighted the new code in the listing that follows:

Finally, add these two new methods to the MainWindow class. The CreateContextMenu is invoked to create the context menu item. It assigns the AddFlowDecision_Click handler to the Click event of this new menu item. The code in the event handler first verifies that the currently selected activity is a Flowchart. If it is, a new FlowDecision activity instance is created and added to the Nodes property of the Flowchart activity.

Testing the Application

After rebuilding the DesignerHost project, you can run it and test the new functionality. Add a Flowchart as the root activity. Right-click to open the context menu for this activity. You should see the new Add FlowDecision menu item. If you select this menu item, a new FlowDecision activity should be added to the Flowchart. Figure 17-11 shows the new context menu item.

Figure 17-11. Flowchart with context menu

Once the FlowDecision has been added, select it and right-click to open the context menu. The Add FlowDecision menu item should now be removed.

Locating the Arguments

At some point, you may need to inspect the input and output arguments for the workflow definition. Their location within the activity model is not necessarily intuitive. They are actually located in the Properties collection of the root activity. To retrieve them, you first retrieve the ModelService from the EditingContext of the designer. You can then use the Root property of the ModelService to navigate to the Properties collection. This is a collection of DynamicActivityProperty objects. Each input or output argument is in this collection along with any other properties.

To demonstrate this, you will modify the handler for the Run menu item to display any arguments that have default values assigned to them.

Modifying the Application

The only necessary change is to add code to the menuRun_Click event handler to access the arguments. Here is the enhanced code for this handler with the new code highlighted:

Testing the Application

Rebuild and run the DesignerHost project to see the new functionality in action. To demonstrate this, you can use the same set of activities that you used in a previous example. Please follow these steps to define the test workflow:

1. Add a While activity.
2. Declare an Int32 variable named count that is scoped by the While activity.
3. Add an Int32 input argument named ArgMax. Set the default value of this argument to 5.
4. Set the While.Condition property to count < ArgMax.
5. Add a Sequence to the While.Body.
6. Add an Assign activity to the Sequence activity. Set the Assign.To property to count and the Assign.Value property to count + 1.
7. Add a WriteLine immediately below the Assign activity. Set the Text property to "Count is" + count.ToString().

Now, select the Run menu item to execute the workflow using the default value of 5 for the ArgMax argument. In addition to the correct results from the execution of the workflow, you should also see the details of the input argument shown in the ListBox at the bottom of the window, as shown in Figure 17-12.

Figure 17-12. Displaying runtime arguments

Summary

This chapter focused on hosting the workflow designer in your own application. The chapter began with a simple application that hosted the major designer components. This same example application was enhanced in subsequent sections of this chapter.

You enhanced this application with the ability to load, save, and run workflow definitions as well as display validation errors. Other enhancements included the ability to reference activities in other assemblies and to automatically populate the Toolbox with activities that are found in loaded definitions. You saw how to override the activity designer that is assigned to standard activities and to locate any arguments in the workflow model. The application was also enhanced to provide a context-sensitive menu and Toolbox.

In the next chapter, you will learn how to execute some WF 3.x activities in the WF 4 environment.