CharlesB Posted June 17, 2014 Report Share Posted June 17, 2014 I hope someone can shed some light on this problem that arose when working on object serialization with JSON API Take a cluster of two elements with an object inside it, make it a variant, and cast the wire of the inner object to LVObject. For this I use the OpenG's LVdata library, that allows to access the contents of cluster as an array of variant. Then, still with LVdata, put it back in the cluster. The variant should be compatible with the original data, but it isn't, you'll get an error 91 (incompatible variant) when converting back to data. If you don't cast, or if you convert to the object that came after the cast, the conversion is fine. You may ask what's the point of this code: from a deserialization, it allows to get data back from a JSON string that represents a cluster with objects inside. So it would be really great if I can make it work! Is it a bug or a "feature"? What can be done to correctly get my data back? Attached the piece of code that demonstrates the problem (LabVIEW 2011). Cluster variant and objects.zip Quote Link to comment
shoneill Posted June 18, 2014 Report Share Posted June 18, 2014 If you insert a "Preserve Run-time Class" primitive on the class after casting to an LVObject it will work. Variants don't know all the intricacies of class types. So between casting the variant to a LVObject and before casting back to a variant, insert the above-mentioned primitive and away you go. Shane. I would also simply name the constant input for the Variant to Data "Object" instead of renaming the item within the variant. 1 Quote Link to comment
CharlesB Posted June 18, 2014 Author Report Share Posted June 18, 2014 Oh OK, so the problem is that the wire type of the variant needs to be of the object type. The fact that it works for objects that are not inside a cluster was misleading, though. In my case, where I don't have the wire type in the diagram (because it's generic code), but only a variant of it, "preserve run-time class" can't be used, so I had to copy give object variant the type of the source object, and it works correctly: Thanks a lot! Quote Link to comment
shoneill Posted June 18, 2014 Report Share Posted June 18, 2014 You're welcome. Quote Link to comment
drjdpowell Posted June 19, 2014 Report Share Posted June 19, 2014 ... so I had to copy give object variant the type of the source object, and it works correctly: Capture d’écran 2014-06-18 à 15.40.46.png What in that little VI that allows you to do that? Quote Link to comment
CharlesB Posted June 19, 2014 Author Report Share Posted June 19, 2014 It flattens / unflattens the variant, replacing its type by the one of the other variant (so it's like a raw type cast): 1 Quote Link to comment
shoneill Posted June 20, 2014 Report Share Posted June 20, 2014 I would go perhaps a step further and make a product request that casting an object to variant should pay attention to the Run-time type which it apparently does not currently do. Although I find the workaround not too cumbersome, I think it can be argued that the function of casting the object to variant should already do something because the object knows at Run-Tme what it's real object type is. Shane. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.