04-04-2026 08:31 AM - edited 04-04-2026 08:41 AM
There is a need to identify an LVClass wrapped in a Data Value Reference (DVR). This is a test VI (LabVIEW 2021). The DVR control and the DVR constant are of the same type.
The name of the class can be obtained from the DVR control by gradually accessing the nested LabVIEWClassControl. No problem here.
I can obtain the same name from the class constant, which is not wrapped in a DVR.
However, the DVR constant puzzles me. I can gradually obtain a reference to LabVIEWClassConstant.
But this data type has no property LabVIEWClassName. An attempt to obtain the value results in error 1048 (only if the property is connected to something).
Bingo! Hacking this reference gives the result. It is crazy, but it works.
What am I doing wrong? What is the right (non-hacking) way to obtain the LVClass name from the wrapped LabVIEWClassConstant?
Solved! Go to Solution.
04-04-2026 09:27 AM - edited 04-04-2026 09:31 AM
Could inspect the Variant directly with the data type parsing palette.
Edit: fair warning I always want to mention when I point people here, any variant returned by this library will have the default value for the type of the variant, for a LVObject that's the class of the wire that was converted to variant rather than on the wire, and it cannot pull the actual value out of a refnum because it operates on the type of refnum not value.
04-04-2026 09:28 AM - edited 04-04-2026 09:48 AM
Hi _Y_,
It is actually not the only example where you have to type cast a reference to achieve VI scripting tasks.
Some other examples:
https://discord.com/channels/1015999107921354932/1121475981912330311/1489603287798775819
https://discord.com/channels/1015999107921354932/1121475981912330311/1489654687845318846
Darren also talks about this in his VI Scripting presentation (slide 48).
Regards,
Raphaël.
EDIT: avogadro5's solution would work if you got the variant value of the DVR constant first, but strangely you have to upcast the DVR constant to a generic constant to be able to select property "Value".
04-05-2026 12:14 AM
avogadro5, could you describe your idea in more details? You modified the VI under test but the script is the same.
Thank you, Raphaël. Darrens presentation shows that the crazy type conversions are not something unusual. This is the answer.
04-05-2026 10:19 AM
You can probably save some scripting by just getting the "Value" property for each of the GObject types you're inspecting and passing it into the data type parsing VIs I showed. It's an alternate, probably faster, way of doing what you're doing.
04-05-2026 08:09 PM
@_Y_ wrote:
...
But this data type has no property LabVIEWClassName. An attempt to obtain the value results in error 1048 (only if the property is connected to something).
That's because when you don't wire the output of a property, the code that would retrieve the property isn't executed.
04-06-2026 03:20 AM
@paul_a_cardinale wrote:
That's because when you don't wire the output of a property, the code that would retrieve the property isn't executed.
Yes. This code shows that the value cannot be obtained. Thus cannot be used to get the class name in the same way as it works for LabVIEWClassConstant
04-07-2026 10:54 AM
This seems to work?
04-07-2026 05:35 PM
I attached an example using the data type palette. No hacking required just an upcast to Constant so the Value property exists.
04-07-2026 06:20 PM - edited 04-07-2026 06:22 PM
wrote:
This seems to work?
Sorry, my question is about parsing an external VI with scripting.
@avogadro5 wrote:
Seems, DVR of Cluster of Class to Class Name.vi is missed in the attached ZIP:(