CustomDataContainer ... where is my GUID ???

dvdg wrote on 10/7/2010, 11:33 AM

Hi there ! i've got some trouble when pushing objects in the CustomDataContainer of medias.

In fact i have two C# file compiled as two dll (A.dll, B.dll). Each dll have the SAME source code (basically two function: one to push a dictionary<string, string> with some key in the container, one to retrieve it).

When i'm pushing stuff with A.dll and retrieving it with A.dll, it works. I've tried to push stuff, close vegas, open it again and retrieve, no problemo.

But when i'm pushing stuff with A.dll and try to get it back with B.dll, the pushed dictionary are not found ! I've even tried to get the bytes array back using B.dll, some stuff are outputed but not all, and it stops halfway without any error (i have custom data on 50 medias, and it stops and truncate after 10)...

That is really weird... has anyone experienced stuff like that ? is there something hidden with the GUID ? in each file (A or B) i initialize my GUID by doing



 Guid myId = new Guid("thebigstringofmyidintheform8-4-4-12hexa");

Is there something "dll linked" with the GUID that would make vegas unable to find back ?

Comments

JohanAlthoff wrote on 10/8/2010, 7:39 AM

This would probably make for a good scripting feature request -- the possibility of enumerating all custom data in an object so you can at least find out where it went.

ForumAdmin wrote on 10/12/2010, 12:43 PM

A few ideas:

1) Custom data is stored in Vegas projects even for Media objects so if you are trying to read data from a project other than the one you wrote to, it will not work.

2) Not all classes in .net are serializable on their own. The generic Dictionary class is apparently one of them. There may be a way to subclass and provide your own serialization method which bring me to my last point...

3) I believe the default behavior for object serialization in the .net framework is assembly and version dependent. If you're serializing a subclass of dictionary in A.dll and you deserialize in B.dll, you may need a shared (possibly signed) assembly that contains the class that is serialized so that both A.dll and B.dll can agree that they're really talking about the same thing.