bjustice

Thanks, great thread! Does anyone know how I might be able to get ahold of, or export all of these cool symbols as BMP files? It looks like all of the extended symbols in the special MCL are stored as "built-in symbols" for the MCL. As such, I can't seem to export them using the method: Custom Item Symbols:Get Symbol. (This method returns an empty data array.)

Kudos, this is very cool

Ha! I now feel silly for responding to your first post with a link back to your own JSONtext branch. Did you encapsulate your object (de)composition into a reuse library of sorts? Or is it pretty entangled in your JSONtext branch? I read through your code and did indeed find that wiki page. Very cool stuff. There are certainly large benefits to doing it the way that you did things in your JSONtext branch. You don't have to inherit from a base class, so all classes become inherently serializable. And there is no need for scripting or creation of data member accessors to allow for the library to do its job. Yeah, we noticed some pretty big limitations to the "Flatten to XML" primitive as well. This tends to leave out fields in the output XML if they are default value in the object.

Thanks JDP for the background information. I just kudo'd your idea.

Our code supports nested and arrays of classes that inherit from the base "Serializable.lvclass" gracefully. Classes are represented as a nested cluster in the serializable string (JSON, XML, TOML) Objects that don't inherit from the base "Serializable.lvclass" are treated in the same manner as JSONtext handles objects... flatten/unflatten from string. If error on unflatten, then return default object

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.

Yes! Did a deep dive through that code as well. We're taking a similar approach

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.

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?

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

sure thing, in work

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?

Per: https://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ I wonder if the fixed point was in some sort of weird BETA state in LV 2009

Not sure if this is relevant, but here is LabVIEW 2019 SP1: Here is LabVIEW 2009 SP1: The hi(x) byte is marked as "Private" within OpenG, but it seems suspicious to me ^

Well, I just encountered a weird issue with the Fixed Point data type. Here is code in LabVIEW 2019 SP1 32-bit: Here is code in LabVIEW 2009 SP1 32-bit: I'm not immediately sure what to make of this

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

yepp, I also found this: https://labviewwiki.org/wiki/Refnum_descriptor

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

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.

I now understand why James made this SubVI for his JSONtext library. I hope that he built this thing with scripting. Brute force, but seems to work well.

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:

I feel the need to highlight the absurdity of how Shaun answered this question within 4 hours... about a post that he made 10 years ago. This community is amazing

Upvote Scratch. I used to teach scratch to 12 year old kids at summer robotics camp. Very approachable, fun to make games. Lego Mindstorm is another good one

Riiight, so Hooovahh is hitting the nail on the head here with my thoughts exactly. It would have been nice to maybe make the plugin menu a bit more intelligent such that it wouldn't have these "create constant, create indicator, create control" for these situations. The consistency argument is interesting and not something that I had considered. Give me 2 months with this new change, and I'll report back on how my muscle memory and opinion has changed. I might indeed be the old man yelling at a cloud right now. I'm trying to beat Darren for fastest programmer in the world, so muscle memory plays alot into things like right click menus and quickdrop names