LabVIEW
Get Variant with type of class dynamically
Solved!
I'm trying to do some introspection on class hierarchies, specifically I need a way to get the parent interfaces of a class without having the class on the block diagram at compile time (eg I only know it's a LV Object). I'm pretty sure I can do this with some VI server ops on the class project items, however I know from experience those are very slow. I found this VI "<vi.lib>\Utility\Data Type\Get LabVIEW Class Parent And Member VI Information.vi"
This is tantalizingly fast, however the challenge I'm having is it operates on the type of the variant input rather than the value. This is fun to wrap your head around initially since class wires have a type in their value, but the crux of it is this VI only operates on the class of the wire that was converted to variant. If I just take a LV Object that contains some arbitrary class data, the type of the Variant is always just LV Object with no parent or interfaces. In order to use this normally you need to have the class wire on the block diagram and convert it to a Variant, which is not what I want.
I just tried this with no luck, the ctl datatype is the cluster inside the ctl not the overall class:
I could maybe get this from a control in a VI that has the correct type, but to do that well I'd need a guaranteed VI name that will always exist and have the proper control in a standard spot which seems flimsy.
Has anyone had any luck "synthesizing" a Variant with a type of any class in memory? Or just knows a fast way to check parent interfaces given a class name or value...
I realized it's a bit hard to understand what I'm asking so I attached a sample project. Given a LabVIEW Object containing "Class 1" I need to get its parent interfaces.
The issue is that I can't use the "Get Class Parent and Member VI" unless the type of the variant is the class I want info about.
I did a benchmark and the Variant VI was over 3000 times faster than the VI server nodes, which I included in the other frame of the disable structure. The only issue is getting the right Variant at runtime.
I've found 2 different ways of achieving this:
Solution 1: Build a variant from scratch (using type string and data string) and use it with "Get LabVIEW Class Parent and Member VI Information". This is very fast but I found the mentioned VI can crash LabVIEW when used repeatedly in a fast loop. Here is the forum thread I created for this: https://forums.ni.com/t5/LabVIEW/Data-type-parsing-VI-quot-Get-LabVIEW-Class-Parent-and-Member-VI/td...
Also, the whole type descriptor of the LabVIEW class is not documented.
Solution 2: Use a private Linker method. It is a bit slower, but it seems more stable. The method not being documented either, it should be tested with more complicated cases to ensure it never misses any interface:
Regards,
Raphaël.
That node and its sibling to write that information to the VIs on disk had in the past repeatedly changes in the datatype of the cluster that is used.
And them being a private node, they did not receive the same attention as official nodes to not crash if wired with incompatible data, respectively to have mutation code update the diagram when a VI is upgraded from an earlier version.Most likely there is also no back-mutation for VIs that are backsaved to earlier version.
These nodes definitely belong in the famous LabVIEW attic. The LabVIEW developers put a lock on that door but any lock can be picked. Behind that door are wondrous things but sometimes also dangerous ones. And there are frequently rusty nails, so thread carefully!
Finally got around to testing the "class control exists" algorithm.
- I was concerned that having an interface in class private data might be falsely detected but this is gladly filtered by the fact that the link type is "Class Private Data" and not "Library."
- I am writing an editor plugin so I was concerned that the linker node would not pick up in-memory edits until they were saved, but it did pick those up despite the file path input.
- For large apps the "AllVis" node gets slower and so does searching the array. My app is 2500 VIs and I found performance was improved by changing the existence test to attempting to open a VI reference to the .ctl by name and using the existence of an error to mean "this is an interface." I found this improved execution speed a bit with a lot of VIs in memory. I expect it is slower for small apps so there isn't a globally "better" approach between the two. If you are certain the VI list is constant over the app lifetime, I expect it would be significantly better to use the VI list, sort it, and cache it between runs.
- This node is not available in RTE. This has some value to me as edit-time only but RTE would be better.
