I was having some issues with a workflow I was developing. I had inserted some LogToHistoryListActivity activities that didn’t seem to be recording the correct values into the history list. I was enlightened by Gabe Hall about something subtle in workflows that became obvious after he said it.
I was setting the HistoryDescription property of my design activity (in my case logToHistoryListActivity1) to the value I wanted. The line looked like …
logToHistoryListActivity1.HistoryDescription = IterationNumber.ToString();
Great, except that this isn’t actually the one that’s running. Because the activity was in a loop WF was doing some special magic to make multiple copies of my activity. What I found that I could do instead is take the sender parameter of the event, cast it to a LogHistoryListActivity and use that instead so the snipit becomes…
LogToHistoryListActivity log = (LogToHistoryListActivity) sender;
log.HistoryDescription = IterationNumber.ToString();
The net result is that I now get the properties of the specific instance set correctly. This is definitely something to think about if you’re putting activities in repeaters, loops, etc.
I was cautioned that sometimes the sender might be null and in which case I’d have to locate the correct activity in the tree manually. However, casting the sender has worked fine for everything I’ve tried thus far.