Activities with Collection Properties + Undo...  
Author Message
ryan.berry





PostPosted: Windows Workflow Foundation, Activities with Collection Properties + Undo... Top

Hello,

I have an activity with a couple properties that are collections and we allow the user to edit these via the standard .NET collection editor. This works great, except that we cannot get edits to these collections to work with Undo\Redo in our rehosted editor. It seems that the serializer used by the undo engine, when serializing specific members, does not serialize collections properly - instead you get the string "(Collection)". Thus making undoing changes to the collection impossible.

Note that serializing the entire activity works as expected (the property is marked with [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)])

Does anyone have any experience with collection properties on activities and customizing undo behaviour I have been snooping around with Reflector but can't determine why the property does not serialize correctly.

Any help is appreciated - thanks.

Ryan Berry




Software Development for Windows Vista5  
 
 
ElifOn - MSFT





PostPosted: Windows Workflow Foundation, Activities with Collection Properties + Undo... Top

 

Hi Ryan,

I don't know what type of collection you are using but i can give you a general information on if it is a serialization related problem or not. Not all the collections can be serialized and deserialized via the workflow serializer. First of all for the DesignerSerializationVisibility.Content to work your collection should be of type IList or IDictionary and the property should be read-only (no setter).

For more information on serialization please see:

http://msdn2.microsoft.com/en-us/library/ms735923.aspx

http://msdn2.microsoft.com/en-us/library/ms171834.aspx

Additionally one alternative to your problem with serialization is to write your own custom serializer.

Hope this helps,

Elif

You might also try using ArrayList instead of whatever collection you have



 
 
ryan.berry





PostPosted: Windows Workflow Foundation, Activities with Collection Properties + Undo... Top

Hi,

I am following the rules for collection serialization - I have a read-only IList with the correct markup. The collection is serialized correctly when I save the entire workflow but is not via the undo engine. The problem seems to be that the XomlComponentSerializationService.SerializeMemberAbsolute method does not properly serialize a collection member.

Ryan

 
 
ryan.berry





PostPosted: Windows Workflow Foundation, Activities with Collection Properties + Undo... Top

Another note - not only is the property not serialized correctly (showing up in XML as "(Collection)"), when the property is deserialized in the undo step, I end up with a collection consisting of what I had before the undo PLUS an additional string - "(Collection)". Obviously not what I want :)

RB

 
 
ryan.berry





PostPosted: Windows Workflow Foundation, Activities with Collection Properties + Undo... Top

My latest findings...

I can change the serialization behaviour of my collection by using a type converter on the property, and modifying the ConvertTo() method.

[TypeConverter(typeof(MyCollectionTypeConverter))]
public List<string> SomeStrings
{
get { return _strings; }
set { _strings = value; }
}

In this way, I can explicitly specify how to convert it to a string. This works for a simple List property and allows me to undo edits to that collection. However, it also requires that there be a setter on the property (if not, the serialized items are ADDED to the collection, rather than replacing the existing items). And of course, having a setter violates the rules for collection serialization, meaning the property can't be saved as part of a workflow definition. Not a problem for us in this specific case (we have some custom behaviour), but still worth noting.

Although the undo serialization process uses ConvertTo to serialize the property, it does NOT seem to use the ConvertFrom method on the TypeConverter when deserializing it (how it determines the deserialization behaviour, I haven't been able to determine). This means I cannot control how the property is deserialized, making it hard, if not impossible, to properly serialize a more complex collection (say a KeyedCollection, or Dictionary). I do not know what the deserializer expects in this case.

Any ideas out there