I asked Tomas to expand on the details of the issue we faced last Sunday and it's this: What’s going is that you wanted to create a custom, reusable composite StateActivity-derived activity. While WF allows you to create an StateActivity-derived class, it restricts a bit what you can actually do with it. The core problem here is that the way you wanted to use the custom activity was similar (in a fashion) to building a custom composite sequence activity. That’s because when you create such a one (like with Add to Project -> New Item -> New Activity) you have full design-time support for creating your composite, including being able to drag & drop activities into the design surface, setting properties, and so on. Unfortunately, the way the ActivityDesigner is composed for the StateActivity class blocks this because it restricts you from modifying the custom activity at design time when opened “standalone”. In other words, it only allows you the complete design-time magic if the parent of the activity is a StateMachineWorkflow (or another StateActivity itself), which would only normally happen when you’re actually designing the real workflow, * not * when creating your composite. (I hope this is clearer, the terminology can get confusing at times). As you correctly pointed out, the way around this would be to create and attach a custom ActivityDesigner to your custom composite StateActivity-derived activity that didn’t have these restrictions. The reason why so much code would be needed, though, is that the corresponding StateDesigner class is internal, and so you can’t directly extend it and just override a couple of methods. Because of this, to accomplish this one would need to completely implement the designer almost from scratch (of course it would be possible, but nasty, to use reflector to grab the core code for StateDesigner and start from there). To be honest, a * lot * of people have complained in the WF
Read More...