The idea:
Make 'Get LabVIEW Class Parent And Member VI Information.vi' work on the type of data on the wire and not only the type of the wire to make it possible to use it together with 'Get LV Class Default Value.vi' so info on classes from source distributions and PPLs can be extracted.
This would make such classes easily available for use in dynamic factory pattern designs.
The reason:
The current implementation of 'Get LabVIEW Class Parent And Member VI Information.vi' cannot give me any info I don't already have access to in development. The only classes it will work on are the ones already loaded/known as it returns result based on the type of wire instead of the type of the class data on the wire. This limitation (as I see it) greatly decreases the use of the VI.
The same can be said for the 'Get LabVIEW Class Information.vi' as can be seen here:
As can be seen the wire needs to, at some point, be present and wired into a 'To Variant' for the VIs to return correct results. This will sadly never be the case for any dynamically loaded class from a PPL or a source distribution!
I use classes widely for extending functionality and often I want to have a dropdown or a list or a tree of classes of a specific hierarchy or interface maybe even filtering the ones that implement a certain dynamic dispatch vi. I have been using config files created from the development environment for this, as a workaround, but in 2020 I wanted to get a live integration of new classes by scanning for new classes, loading them and registering their data. (In practice what I'm doing today is that I copy a PPL containing classes into a common PPL folder and register the classes and their heirarchy/members in a config file. This makes the new classes available to the application without a need for rebuilding it.)
An example could be a UI element that allows the user to launch an actor from a ring control. So what types of actors are available? The application cannot know this. Any actor that comes from a PPL or a source distribution will be unknown so the application cannot properly populate the ring control. It is possible to find all classes by looking at the extension, but not what hierarchy they belong to. In 2020 this could have been done using the following code (if it worked as I suggest):
Sadly this will never return anything useful as it can only look at the LabVIEW Object wire.
I guess all the other data type VIs work in the same way, however that has never been an issue as the data types could only be mixed when they were variants already and there isn't (to my knowledge) a load data type by name/enum VI.
In my dream scenario I wouldn't even have to load the class into memory to acquire the info. A path based version of 'Get LabVIEW Class Parent And Member VI Information.vi' would be perfect for use with dynamic factory patterns. This is however a minor issue as the data can be stored between executions instead, but one can dream right :).
Sorry that my ideas/requests always end up being walls of text...
