WF DependencyProperty vs. WPF DependencyProperty

I had blogged about DependencyProperty in detail and its implementation in WPF. As it turns out WF has it own version of DependencyProperty which is also used nearly for the same purpose of Data Binding, Attached Properties, etc. I guess the MS teams were too busy back then in their own stacks and wanted to avoid any cross dependencies on each other. Hopefully these types would see a merger in 4.0 framework with consolidation of XAML; all moving entirely to a different assembly. Below are the different APIs currently available for WPF/WF frameworks:

//WPF
System.Windows.DependencyProperty.Register(“Name”, typeof (dataType), typeof (parentDataType),
new System.Windows.UIPropertyMetadata(0, null, null), null); //def. value and callbacks

//WF
System.Workflow.ComponentModel.DependencyProperty.Register(“Name”, typeof (dataType), typeof
(parentDataType), new System.Workflow.ComponentModel.PropertyMetadata (
System.Workflow.ComponentModel.DependencyPropertyOptions.Metadata)); // type of property

Don’t they look like two departed brothers in Kumbh Ka Mela

WF Rules Engine Session

I will be taking a session on WF Rules Engine this weekend for BDOTNET user group (you can find more details about it on the user group’s website). This would be a thorough walkthrough on WF Rules & motivation behind using them. Plus I will be demonstrating some of the community samples which I have extended to further leverage on this wonderful piece of technology. Looking foward to meet you all .

Issues using Workflow with Code Separation (.xoml)

There are many benefits creating a workflow with code separation. Standout feature is if you want Rehost the workflow you will need to supply the xoml file as the input (you can find Re-hosting sample here). Inspired by that I started with creating workflow with code separation model.

But it wasn’t long before I realized that this approach had some limitations.

1      You can’t have constructor in the code behind file. This is normally a area for initialization of properties. Not having one can cause issues. Fortunately I found a workaround to override a method called InitializeProperties which is part of base class called DependencyObject.

public partial class Workflow1 : SequentialWorkflowActivity

{

        protected override void InitializeProperties() // override here

        {

            base.InitializeProperties();

            dataHelper = new DataHelper(); // look ma, put initialization here

        }

}

 

2      You won’t be able to access the activities in the code behind. Let’s say you have a replicator activity & you want to access the current child data. But unfortunately intellisense won’t work in code behind. Remember that xoml file is parsed & compiled at the time of compilation only, unlike the default workflow with code model that creates a partial class at design time itself and inturn forces us to use InitalizeComponent method.
Error: activity.CurrentChildData[activity.CurrentIndex]; (Not possible to access your activity in codebehind)
There can be 2 solutions to this issue:

a.       Use the activities collection to retrieve activity. The collection anyways would be populated at runtime:
ReplicatorActivity replicatorActivity =

                (ReplicatorActivity) this.Activities["myReplicatiorActivity"];

Object data = replicatorActivity.CurrentChildData[replicatorActivity.CurrentIndex];  

b.      Previous one although works fine & might be mandatory for couple of scenarios, but as a better approach you can use a activity’s handlers to assign required values to local variables. For instance to capture the current child data, I can create a property called Data & retrieve its value by hooking into Replicatior Activity’s ChildInitialized event handler.

 

public Object Data { get; set; } // Property here

private void replicatorActivity1_ChildInitialized(object sender, ReplicatorChildEventArgs e)

{

            Data = e.InstanceData; // Extract the value

}

 

Hope this helps .

(Update: The second issue outlined by me above is more of ReSharper issue. You need to use VS.NET Intellisense instead of ReSharper’s to avoid it. But nevertheless, if you are moving your workflows to a non-workflow (e.g. Web App) project, my solution is still quite useful).