A few weeks ago, there was a post on the Advanced Workflow blog (an
excellent resource, which I recommend you take a look at) about spawned
contexts
and how it affects activities (or rather, code related to
activities) nested inside activities such as Replicator, While and so on. This
is an issue that can be quite confusing and it's easy to write code that won't
work correctly under these circumstances (one of the dangers of writing too much
code behind your workflow, I'd say).

I've seen a few posts on the Windows
Workflow forums
from people that have been bitten by this issue, such
as this
one
, and it got me thinking about whether using Activity Binds instead
of directly modifying properties of activities in code (event handlers) might
simplify this. As far as I can tell, it indeed works just fine under beta 2, and
it seems to me like it can lead to a slightly more elegant solution than what I
proposed as the solution for that particular post.

Here's a similar example that instead defines a read-only property on the
workflow class that returns the current member of an enumerator over the
collection and then simply binds the relevant property of the activity in the
While loop to the workflow property. Works much nicer, I think.

private List members;

private IEnumerator enumerator;



public MemberInfo CurrentMember

{

   get { return enumerator.Current; }

}



public Sample2()

{

   InitializeComponent();

   members = MemberInfo.GetMembers();

   enumerator = members.GetEnumerator();

}



private void WhileCondition(object sender, ConditionalEventArgs e)

{

   e.Result = enumerator.MoveNext();

}

You can see the code for the example here.
Sample1.cs contains the original proposed solution, while Sample2.cs contains
the new one using binding. That said, I'm still not totally happy with it. It
still requires some code to put everything together and it's not quite as
"declarative" as I'd like...


Tomas Restrepo

Software developer located in Colombia. Sr. PFE at Microsoft.