Need LVOOP Object VIs in lvdata library

[Jim Kring]

It would be nice if there were some VIs for dealing with LVOOP Objects, at run time. One VI that I would love is one that could convert an LVOOP Object to a cluster (and vice versa). Ya, I know that this would violate encapsulation (shhh... don't tell AQ), but it would allow us to do stuff like create flexible object serialization tools.

[Tim_S]

To flaunt my ignorance, can you explain "object serialization tools"?

Tim

[Jim Kring]

Tim: Basically it's a fancy way of saying "flatten" (and "unflatten"). Here's a Wikipedia link to a more formal definition. For example, you could convert an object into a cluster and then write all its data to an INI file using the OpenG Variant Configuration File IO VIs.

[Tim_S]

Ah, got it.

I've got a calibration object with name, physical channel, scaling, etc... The object has methods to save to and load from XML file. I've coded the serialization into the object. (Hope I'm using the terms right.) Wouldn't this be the appropriate place?

Tim

[Jim Kring]

Ah, got it.

I've got a calibration object with name, physical channel, scaling, etc... The object has methods to save to and load from XML file. I've coded the serialization into the object. (Hope I'm using the terms right.) Wouldn't this be the appropriate place?

Tim

Ya, that's a good place to do it yourself.

[jgcode]

FWIW this is a work around I use at the moment when I want a human readable file.

Adding a non-type def cluster to group the items I want to flatten to disk

Here is (part of) a Class API

The Read From Disk method delegates read/writing to another object (so I can change file format etc...)

In this example the Base File Class writes a config file (OpenG style) I have a reuseable VI from my own library:

That is a wrapper for the OpenG VIs to guarantee certain functionality

I can handle file versioning to (not shown here).

In this example this creates a nice config type (settings) file.

The cool thing about OpenG is that this supports inheritance - as long as the variable names are unique up the chain - I can write to the same section.

I have found that MGI VIs do not allow this as they write the section as a string as opposed to key-value pairs (config API).

I have to say using the native XML is much easier tho.

----

Jim have you done any prototyping of your idea?

[mje]

I have often wanted similar features to Jim, or mainly some way to perform type reflection at runtime so as not to violate the very important encapsulation. This would allow for some very powerful serialization methods to be (dynamically) defined. I would also love to explore the possibility of late binding should such a system ever exist, but that's a whole other can of worms...

JG's idea is interesting though, as it still allows automatic serialization via the anonymous cluster. I like it! Extra kudos for the serialization method itself, if it's dynamic each level in the hierarchy gets a crack at serializing. Even more kudos for abstraction the file interface!

Edit: I misread part of your last post, doesn't look like there is an abstracted file interface. What can I say, it's late and I'm tired. Also appears not to be a way to "like" a post from the mobile version of the site. /sadface

[jgcode]

Edit: I misread part of your last post, doesn't look like there is an abstracted file interface. What can I say, it's late and I'm tired. Also appears not to be a way to "like" a post from the mobile version of the site. /sadface

I am on iphone and can like using the button on the top right hand corner of a post (tick symbol).

I might be misinterpreting 'Abstract File Interface'? But the File Interface Class is a dependency from another package. The Interface Class' default behavior is to use OpenG format (as using LVOOP why just have an functionless based Class and extra Child? - I prefer less work )

One issue with the implementation is that the interface (as in a Connector Pane context this time) is a variant. This may seem a little dirty but it means the Cluster does not have to be a type-def (preventing issues of a TD Cluster in a Class) and that the File Interface can be re-used across or in other Classes.

[mje]

Is that what the checkmark does? I couldn't figure out what I was doing by taping it...

Don't mind my ramblings about file interface. I should learn not to make any posts after midnight.

[PaulL]

We, too, would very much like to serialize objects more easily.

We actually do serialize objects to XML now, but we write a serialization method for each class (and this method calls the parent method, if applicable). Writing a custom method for each class is a fair amount of work and undesirable when there opught to be a framework that supports this automatically. (Note that the native XML functions do provide a framework that serializes objects, but the XML format is not satisfactory for all purposes, as stated elsewhere previously. In particular, if an object has a default value the generated XML just says that, rather than specifying the actual values, which makes the XML output to any application that doesn't have the exact same class definition. NI could just make a new version of their XML VIs that would format data better--which is probably pretty easy--and that would probably be a fine solution for many of us. In the meantime LabVIEW developers need to do this, and that is I think why we are having this discussion.)

Using a cluster within an object will also work (we do use this approach, actually, with configuration files, although for this purpose we use the native XML VIs), although it doesn't support (I don't think) writing parent data or objects within the cluster. More importantly, there ought to be a way to serialize every object, not just a cluster within the class. (Using a cluster does negate some of the points of using an object in the first place, like maintaning history, although this is more important in some situations than others.) Mostly, I don't think developers should have to do this. It should be easy (trivial, actually) to serialize objects, in my opinion, to an interchangeable format such as XML. (Java and other languages have frameworks to do this. Why don't we?)

[Yair]

Admin Edit: The below series of four posts were moved from the Timestamp support for Format into String & Scan Variant From String (String Package) thread to here.

On a somewhat related note, any chance of correctly recognizing LVOOP wires? Last I checked, they were recognized as refnums.

[Jim Kring]

On a somewhat related note, any chance of correctly recognizing LVOOP wires? Last I checked, they were recognized as refnums.

Hi Yair. Great idea! I've posted something similar, here: Need LVOOP Object VIs in lvdata library

[Yair]

Well, I would start with just recognizing that the variant is an LV class. From what I posted here, it seems I did find a way of finding out (although I don't remember what the code looks like).

Alternatively, since OpenG is now in 2009, we can probably use the vi.lib variant VIs, which I assume do tell you if the variant is a class, so if it's a refnum, you call the vi.lib VI to get the actual type. Optionally, we could also ditch the entire type string code and simply use the vi.lib VI for everything and simply make a lookup table for all the existing OpenG types, but that might have performance and backward compatibility issues.

[Jim Kring]

Well, I would start with just recognizing that the variant is an LV class. From what I posted here, it seems I did find a way of finding out (although I don't remember what the code looks like).

Alternatively, since OpenG is now in 2009, we can probably use the vi.lib variant VIs, which I assume do tell you if the variant is a class, so if it's a refnum, you call the vi.lib VI to get the actual type. Optionally, we could also ditch the entire type string code and simply use the vi.lib VI for everything and simply make a lookup table for all the existing OpenG types, but that might have performance and backward compatibility issues.

Yes, the VIs that ship with LabVIEW do support determining if a variant contains an LVClass instance.

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

[jgcode]

Yes, the VIs that ship with LabVIEW do support determining if a variant contains an LVClass instance.

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

I have previously exposed these VIs in this package but I have always thought it would be good to expose these VIs in the OpenG LabVIEW Data Library as a linked sub-palette.

I will start a new thread if there is any interest?

[Yair]

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

Just to clarify, I meant adding the LV class value to the OpenG enum and then modifying Get TDEnum from Data__ogtk.vi along these lines:

The alternative implementation might be faster, because it hopefully does not require flattening the variant.

[Jim Kring]

Just to clarify, I meant adding the LV class value to the OpenG enum and then modifying Get TDEnum from Data__ogtk.vi along these lines:

The alternative implementation might be faster, because it hopefully does not require flattening the variant.

Hi Yair. Thanks for the clarification. I see what you mean.

I'd be curious to know if this is much faster.

[Aristos Queue]

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

I'm confused. Please define "native implementation". That VI is doing exactly what LV does under the hood in the C++ code. I'm not sure how much more native you can get.

And, to answer Yair's question, no, there's no flattening of the variant involved.

[Jim Kring]

I'm confused. Please define "native implementation". That VI is doing exactly what LV does under the hood in the C++ code. I'm not sure how much more native you can get.

And, to answer Yair's question, no, there's no flattening of the variant involved.

Native implementation, to me, means that it uses primitives other than a Call Library Function or Code Interface Node (unless it's to call to LabVIEW.exe and the code is guaranteed to work at Run Time in both desktop and real-time).

I guess I don't really trust stuff that's inside password protected VIs and that's not in the palette. It could get removed or put into an LVLIB and scoped as private

[Yair]

Well, in any case, it looks like the OpenG version is considerably faster (I see ~20 ms for OpenG vs. ~300 ms for the vi.lib VI), so that answers that, at least.

[Jim Kring]

Well, in any case, it looks like the OpenG version is considerably faster (I see ~20 ms for OpenG vs. ~300 ms for the vi.lib VI), so that answers that, at least.

I see the same thing -- that's interesting.

[candidus]

Hi there,

I recently wished the OpenG "Get Cluster Element by Name" would work on OO wires...

I looked a bit deeper into this, found out that OO wires unsurprisingly aren't mere clusters but that their flattened form is documented in the LV wiki.

So I began to write a VI that parses the flattened OO data and returns the contained data clusters. Here is it:

Admittedly, I felt a little bit dirty when writing this code :-)

Looking for another solution I stumbled upon the LV XML primitives. As mentioned before, these can be used to do much the same, with some limitations. I was only interested in readonly access of basic data types, so it worked for me:

I never used these methods in production code, however.

candidus

[Jim Kring]

I recently wished the OpenG "Get Cluster Element by Name" would work on OO wires...

I looked a bit deeper into this, found out that OO wires unsurprisingly aren't mere clusters but that their flattened form is documented in the LV wiki.

So I began to write a VI that parses the flattened OO data and returns the contained data clusters. Here is it:

This is very cool. How do you use it in practice? For example, how do you get the Class Private Data Hierarchy (Type)? Is there any way to obtain this from Object in?

[candidus]

Is there any way to obtain this from Object in?

Unfortunately I didn't find a way to obtain that information. I provided the appropriate cluster types manually. Just a thought: Can we open a reference to the class private data control and get it from there?

[candidus]

I have figured something out: That sucks...

Joking aside: It seems we can obtain the data type information, but we have to use LVClass references and property nodes to get the ancestor hierarchy. I created a small ClassInfo library and an example:

ClassPrivateData.zip

However, there's another way to get the data of the current class only:

It uses the VI "Get Mutation History.vi" from vi.lib to get the class private data type as Variant.

That's all far away from being an OpenG-ready solution but at least it seems to work in the runtime engine of LV2010.

I had problems with the runtime engine of LV2009, the VI executes but becomes broken after it has finished.