Leaderboard

We adopted the notion that classes must inherit from a base "serializable.lvclass". This activates the Project Provider plugin (project tree scripting methods). We didn't see a convenient way around this, and we didn't see this as too much of an inconvenience. Where we noticeably diverged from AQ Char Lineator is that we (through scripting) create a "SerializableData" cluster typedef that gets dropped into the class private data. Only data within this cluster is consumed by the serialization framework. all other data is ignored. This simplified things in that we only need a single future-proof data read/write accessor for this cluster. A user can update serializable data by only editing this typedef... they don't have to touch any VI source code. Pros and cons to this solution.

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: https://bitbucket.org/logmanoriginal/jsontext/src/lvobjectserialization/ paid 3rd party library "JSON Object Serialization by GCraftsman": http://sine.ni.com/nips/cds/view/p/lang/en/nid/215788

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.

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.

My informations from inside NI is that this is largely untrue. NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support 😮 I don't have much details but different sources corroborate this.

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

sure thing, in work

Well, the reverse engineering was quite some work as I had to view many different existing CDF files and deduce the functionality of them. But creating a new one for the sqllite library itself should be straight forward by taking the one for lvzip and changing the relevant strings in the CDF file. Only thing besides that is that you need to generate also your own GUID for your package as that is how Max identifies each package. But there are many online GUID generators that can do that for you, and the chance that that will conflict with any GUID already in use is pretty much non-existent. Depending if you also want to support sqllite support for Pharlap and VxWorks you would have to either leave those sections in the CDF file or remove them. You can also handle dependencies and depending on what libraries you need they may actually exist as packages from NI already. Adding such dependencies to your CDF file is basically adding the relevant GUID from that other CDF file and version number to your own CDF file. Works quite well but if NI doesn't have the package available already, things can get more complicated. You either have to create an additional CDF file for each such package or you could possibly add the additional precompiled modules to the initial CDF file. A CDF file can reference multiple files per target, so it's possible but can get dirty quickly.

- LVCompare and LVMerge should be unlocked with the LabVIEW base edition. Or even better, an open source merge and compare tool could be released to the community.