Jump to content

Return class cluster type?


Recommended Posts

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.)

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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."

Link to comment

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"?

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Oh, that was it... :P

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.

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.

Guest
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.