I noticed this in a rehosted designer and I would consider this as a bug: Under certain circumstances, if you collapse a composite activity it changes it's parent because the designer assumes you are dragging it.

The conditions are pretty difficult to reproduce, so I will do my best to describe it:

Assuming you have very wide activity like a SwitchCaseActivity with a lot of branches (an IfActivity will do, too, but the more branches, the higher the chances to reproduce), one of the very right branches contains a composite activity that is very wide, too, i.e. contains a lot of other composite activities. The SwitchCaseActivity must be so wide, that you have to scroll the designer to the right, to see it.


| SwitchActivity |


| ---------- ---------- ---------------------------------------- |

| | Case1 | | Case2 | | LargeCase | |

| |--------| |--------| |--------------------------------------| |

| | | | | | ------------------------------------ | |

| | | | | | | Large CompositeActivity | | |

| | | | | | |----------------------------------| | |

| | ------ | | ------ | | | | | |

| | | Act| | | | Act| | | | | | |

| | |----| | | |----| | | |----------------------------------| | |

| | | | | | | | | | | |

| | |----| | | |----| | | | |

| |--------| |--------| |--------------------------------------| |

I hope the ASCII image clarifies the layout a little bit. Now make sure that your work space is small enough so that you have to scroll right, to see the LargeCase activity, so that a couple of branches on the right are not visible.

NOW: Position the mouse on the little [+] in the upper left corner of the Large Composite Activity and click to collapse the activity. The whole branch "LargeCase" resizes with it and gets smaller. The scrolling position changes, because the whole needed space gets smaller. If now another case, e.g. Case2, ends up under the mouse after all the resizing, then the "LargeCompositeActivity" ends up to be in that Case branch.

So by collapsing an activity you might unintentionally drag that activity to other activities.

Re: Windows Workflow Foundation weird workflow designer behavior


How common is this scenario for you What¡¯s the workaround you have implemented to make your app usable

Re: Windows Workflow Foundation weird workflow designer behavior


Well, it is in my opinion a bug, it happens of course rarely as it depends on workspace size, drawing size of the workflow in the designer and the right combination of collapsing an activity so that the workflow resizes and it then ends up in a different part of the workflow. Despite that these criterias have to be met to cause this behavior, I rebuild a part of a workflow because if it as I thought I accidentally deleted it, but it did just end up in a different part.

As far as I can tell there is no workaround as the designer can be rehosted, but it is a blackbbox. Trying to capture this in the root designer of the workflow might be possible, but it would be a very fuzzy thing to write.

Re: Windows Workflow Foundation weird workflow designer behavior


Thanks for letting us know. We are investigating possible solutions.