Jump to content

OpenG and Object compatibility

Recommended Posts

I did a deep dive into JSONtext, JKIJSON, and into EasyXML.
I made a few interesting observations after doing a bunch of work to integrate object serialization into a branch of these libraries.
Basically, beware usage of OpenG LabVIEW Data Palette SubVIs when working with LabVIEW objects


1) The OpenG TD doesn't include "LabVIEW Class Instance" (or any of the new datatypes either... maps, sets)



2) In the following code, note how the top method produces an error, but the bottom method is fine:



3) In the following code, note how the top method produces an error, but the bottom method is fine:


  • Like 1
Link to comment

At an absolute minimum, would there be any interest here in releasing a new update for the OpenG LabVIEW Data VIPM package to include the following datatypes in the OpenG TD?:

  • LabVIEW Class instance
  • Map
  • Set

It seems like this would be an easy and backwards compatible update.
I make this request because legacy code such as EasyXML heavily leverage the OpenG TD.  It would be minor hassle to replace this with the native LV TD.

Link to comment

Relevant test in LabVIEW 2019 SP1.
It looks like the Lo(x) of index:1 is no longer enough information to discern between a refnum and a LabVIEW Class Instance.  I need to figure out how to properly differentiate between Refnum and LabVIEW Class Instance


Link to comment

Ok, so, now knowing this information, it seems like the following needs to happen:

  • Add the following to: "Type Descriptor Enumeration__ogtk.ctl"
    • "Fixed Point"
    • "Map Collection"
    • "Set Collection"
  • Add the following to: "Refnum Subtype Enum__ogtk.ctl"
    • "LabVIEW Class Instance"
  • Update the holy LabVIEW wiki

It's interesting to learn here that we can't 1:1 match "Type Descriptor Enumeration__ogtk.ctl" to "NI_Data Type.lvlib:Data Type.ctl" since these are inherently different

Link to comment

Per: https://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/


The first word (16 bits) in any type descriptor is the length, in bytes, of that type descriptor, including the length word. The second word (16 bits) is the type code. LabVIEW reserves the high-order byte of the type code (the xx in the following tables) for internal use. When comparing two type descriptors for equality, you should ignore this byte.

I wonder if the fixed point was in some sort of weird BETA state in LV 2009

Link to comment
2 minutes ago, bjustice said:

Interesting, "Only used internal to LabVIEW" was a conscious decision within the OpenG toolkit.

Any notion why this was the case?  Is it time to reverse this decision?


Hmmm... that was a long time ago :)  I'm not totally sure what the thinking was.

I don't see any problem renaming the enum value to "ByVal Class" (or similar).

Link to comment
1 hour ago, bjustice said:

I was going to use "LabVIEW Class Instance" in an effort to somewhat standardize with the modern NI datatype palette:



Sounds good.


38 minutes ago, bjustice said:

LabVIEW 2013 SP1 32-bit yields proper behavior for fixed point:


Just to confirm, do we want to continue to build this OpenG VIPM package for LabVIEW >= 2009, or upgrade to LabVIEW >= 2013?


Yes, we'll upgrade the sources to LV2013 (and separate compiled code on all VIs).

Let's do this, first, as a single, separate commit to git.

Then, we can make the other changes.

Link to comment

If you are interested in object (de-)composition, I have a library that does most of the heavy-lifting (extracting private data and putting it back together), including functions to work with clusters of any size and shape. I can save it back to LV2017 and post here.

  • Thanks 1
Link to comment

I would certainly be interested in taking a look.

Internally, we made the early decision that we didn't want to directly access class private data through string flattening or by inspecting the class' *.ctl file.  We felt that this violated the covenant that class data should only be accessed through data accessors.  As such, we moved towards a Project Provider plugin framework that scripts accessing of class private to work with our serialization engine.

  • Like 1
Link to comment

While researching this, I discovered 2 other projects that solved serialization of objects using (de-)composition of private data using the flatten to string and TypeDescriptors:

JSONtext branch with object support:

paid 3rd party library "JSON Object Serialization by GCraftsman":

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.