Return class cluster type?

[PaulL]

OK, I've parsed a LabVIEW object from a binary string (see thread here: Flattened LVOOP Class). Is there a way I can programmatically retrieve the cluster to use as a type (not just the type descriptor as a string) so that I can create a cluster with the object data?

(This may not be necessary for what I am doing but I want to know if there is a way to do it. I haven't found a way.)

[Jim Kring]

QUOTE (Paul_at_Lowell @ Apr 23 2009, 05:33 PM)

OK, I've parsed a LabVIEW object from a binary string (see thread here: http://forums.lavag.org/Flattened-LVOOP-Class-t11256.html&p=47637#entry47637' target="_blank">Flattened LVOOP Class). Is there a way I can programmatically retrieve the cluster to use as a type (not just the type descriptor as a string) so that I can create a cluster with the object data?

(This may not be necessary for what I am doing but I want to know if there is a way to do it. I haven't found a way.)

If you can get the Type Descriptor of the lvclass private data, there's an OpenG VI for returning the default data as a variant.

[PaulL]

QUOTE (Jim Kring @ Apr 23 2009, 06:23 PM)

If you can get the Type Descriptor of the lvclass private data, there's an OpenG VI for returning the default data as a variant.

Ah! Thanks, Jim! The "Flattened String To Variant" (with a "type string" = Type Descriptor input) function appears to be what I needed.

Paul

[Jim Kring]

QUOTE (Paul_at_Lowell @ Apr 24 2009, 09:51 AM)

Ah! Thanks, Jim! The "Flattened String To Variant" (with a "type string" = Type Descriptor input) function appears to be what I needed.

Paul

Great. BTW, how are you getting the Type Descriptor of the LVClass private data? I didn't notice the private data type descriptor in the flat data or type descriptor of the object data or type descriptor and I couldn't find any utility VIs (in vi.lib, for example) to do this either.

-Jim

[PaulL]

QUOTE (Jim Kring @ Apr 24 2009, 03:23 PM)

Great. BTW, how are you getting the Type Descriptor of the LVClass private data? I didn't notice the private data type descriptor in the flat data or type descriptor of the object data or type descriptor and I couldn't find any utility VIs (in vi.lib, for example) to do this either.

-Jim

Please see the attached image.

Paul

[Francois Normandin]

There's an API that you might want to look at.

Here's the latest package (not yet uploaded to CR) .

Download File:post-10515-1240631352.vip >LV 8.6

[Jim Kring]

I could be wrong, but I'm pretty sure that this method (using VI Server to open an LVClass reference) won't work in built executables.

[Francois Normandin]

QUOTE (Jim Kring @ Apr 25 2009, 12:59 AM)

I could be wrong, but I'm pretty sure that this method (using VI Server to open an LVClass reference) won't work in built executables.

You're right... It's not available in the RT engine. (I don't usually think in those terms)

[PaulL]

QUOTE (normandinf @ Apr 25 2009, 09:11 AM)

You're right... It's not available in the RT engine. (I don't usually think in those terms)

Just for the record:

The context help window for "Property: VI Reference" states: "Available in the LabVIEW Run-Time Engine: No."

The detailed help has the following, however: "Note The LabVIEW Datalogging and Supervisory Control Module supports this property in the Run-Time Engine." I'm guessing this only applies to shared variable library elements? In any case, since we are using the DSC Module, I gave it a try. The application returned Error 1055: "Property Node in LVObjectParser.lvclass:determineClusterTypeString.vi->flattenObjectToStringThenVariant3.vi."

[PaulL]

QUOTE (normandinf @ Apr 24 2009, 08:54 PM)

There's an http://forums.lavag.org/LVClass-API-file152.html' target="_blank">API that you might want to look at.

Very nice API for some of our purposes! Thanks for alerting me to this.

[Francois Normandin]

QUOTE (Paul_at_Lowell @ Apr 27 2009, 04:40 PM)

Very nice API for some of our purposes! Thanks for alerting me to this.

You're very welcome.

I understand why those methods and properties are not writable during execution (it's been explained plenty of times that we can't write anything that would change the VI code while it's running and I guess it's the same with lvclasses), but I'm still wondering why we can't access them as "read-only"?

[Jim Kring]

QUOTE (normandinf @ Apr 27 2009, 03:20 PM)

You're very welcome.

I understand why those methods and properties are not writable during execution (it's been explained plenty of times that we can't write anything that would change the VI code while it's running and I guess it's the same with lvclasses), but I'm still wondering why we can't access them as "read-only"?

My guess is that anything in VI Server that is a project or project item is deemed part of the "editor" and not needed at run-time. A line has to be drawn somewhere, and LVLIB references are on the "editor" side of the line.

[Aristos Queue]

QUOTE (Jim Kring @ Apr 27 2009, 05:49 PM)

My guess is that anything in VI Server that is a project or project item is deemed part of the "editor" and not needed at run-time. A line has to be drawn somewhere, and LVLIB references are on the "editor" side of the line.

Yep.

[Jim Kring]

QUOTE (Aristos Queue @ Apr 27 2009, 03:50 PM)

Yep.

That's funny. I was thinking to myself, "How would AQ explain this?", as I was writing that post

[Francois Normandin]

QUOTE (Jim Kring @ Apr 27 2009, 06:49 PM)

My guess is that anything in VI Server that is a project or project item is deemed part of the "editor" and not needed at run-time. A line has to be drawn somewhere, and LVLIB references are on the "editor" side of the line.

I partially agree. A project is only available in the development environment. But a lvclass (lvlib/llb/...) can be used with a plugin architecture. That's a resource I'd like to tap in when I'm in the runtime environment. If you can dynamically load a class, why not access it's constituents (datatype, tags, icon, etc.) in read-only? I'd argue the editor line is not where it should be. There are tons of VI properties that are read-only in run-time while being read-write in the development.

[Aristos Queue]

QUOTE (normandinf @ Apr 28 2009, 12:13 PM)

I partially agree. A project is only available in the development environment. But a lvclass (lvlib/llb/...) can be used with a plugin architecture. That's a resource I'd like to tap in when I'm in the runtime environment. If you can dynamically load a class, why not access it's constituents (datatype, tags, icon, etc.) in read-only? I'd argue the editor line is not where it should be. There are tons of VI properties that are read-only in run-time while being read-write in the development.

I'm surprised you couldn't hear my cry of frustration back in 2006 when I realized that someone had coupled the library interface to the project interface... unfortunately, we're tied to it now and there's no way to change it without breaking all user VIs to create a separtate refnum hierarchy independent of ProjectItem.

LV Classes have tried to expose out functionality for the runtime engine that we think is useful in various utility VIs. The most important two are in the palettes (one appeared in 8.5, the other in 8.6). You can find others here:

vi.lib\Utility\LVClass

Please note that the ones not in the palettes may be removed/refactored/renamed between LV versions. This is basically my hiding place for lvclass functionality that multiple customers ask for but for which I don't have time to make a nice, stable, documented interface.

[Francois Normandin]

QUOTE (Aristos Queue @ Apr 28 2009, 01:45 PM)

I'm surprised you couldn't hear my cry of frustration back in 2006 when I realized that someone had coupled the library interface to the project interface...

Oh, that was it...

QUOTE (Aristos Queue @ Apr 28 2009, 01:45 PM)

...and there's no way to change it without breaking all user VIs to create a separtate refnum hierarchy independent of ProjectItem.

We all have to live with our past.

Thanks for the explanation.