Serialize JSON to *Variant* LVObject

[Jim Kring]

For my use case, I would prefer if Serialize JSON to LVObject.vi output a variant instead of a generic LabVIEW class object.

However, maybe I’m doing something wrong or not calling the right API methods to do what I’m trying to accomplish.

The reason I’d like this feature/change, is that I am calling JSON text to Variant.vi in a loop (getting a variant on each iteration) and then converting the array of variants into a variant cluster.

However, because JSON text to Variant.vi in calls Serialize JSON to LVObject.vi which returns a generically typed labview object, I then end up with a cluster whose elements are generic objects. And, then when I try to call LabVIEW’s Variant to Data function to convert to a cluster with my specific object types, it returns an error – it refuses to downcast the individual elements of the cluster. Instead, I have to use generically typed lvoop objects in my cluster and then convert each element to a more specific type later.

Again, the fix for my use case would be to have the Serialize JSON to LVObject.vi method return a Variant (with my specifically typed class) instead of an LVObject (as a generically typed class).

‌

‌

[Jim Kring]

Thinking out loud, I think a workable solution/spec would be the following:

• Add a new dynamic dispatch method to the object serializer base class named Serialize JSON to Variant LVObject.vi

  • configure the serializer base class to NOT require overriding this new method (i.e. set must override attribute to false)
  • have the default implementation of Serialize JSON to Variant LVObject.vi call the existing Serialize JSON to LVObject.vi method

• modify JSON text to Variant.vi so that it calls the new Serialize JSON to Variant LVObject.vi

For users, this means that…

• If a user has an existing application, then it will continue to work as it always has, since the default implementation of Serialize JSON to Variant LVObject.vi call the existing Serialize JSON to LVObject.vi method
• If a user overrides the new Serialize JSON to Variant LVObject.vi they can get the new and improved behavior.

‌

[James Powell]

What LVClass Serializer are you using?

[James Powell]

I ask because I just wrote a unit test to verify that the default Serializer seems to work fine:

‌

[James Powell]

Add unit test for child objects and parent wires, see Issue #209

→ <<cset fd0f2464165e>>

[James Powell]

I think I identified the difference: My VArray to VCluster function (JDP Utility.lvlib:Array of Variants to Cluster.vi) returns a Variant containing a Cluster of Variants. But your OpenG function returns a Variant containing a Cluster of specific types. For some reason, The Variant to Data primitive can handle Child-Objects in the first but not the second (which sounds like a bug to me).

This is my test case that throws an Error 91:

And this is the modification that works (I am effectively changing Variant Cluster, containg LVObject with Child Class to Variant Cluster-of-Variants, with second Variant containing a LVObject with Child Class.

‌

So I would recommend you try swapping out the OpenG VCluster functions with the ones from JDP Sci Common Utilities. I’d sugest dropping the renaming functions as well as unneeded, since teh Variant-to-Data primative ignores all names anyway.

‌

[Jim Kring]

nice detective work, James! I’ll probably try fixing by wrapping these objects in a variant, to work around the LabVIEW bug (I’d call it a bug). I’ll try filing a big report too.

[James Powell]

Closed as an NI bug