Make 'Get LabVIEW Class Parent And Member VI Information.vi' work on data and not only type

[HenrikDueholm]

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

[wiebe@CARYA]

Wouldn't this return the object's name?

I'm not sure if that's the point. Haven't needed your point yet.

Perhaps I'd require a TL;DR version 😁.

EDIT: Never mind. I missed "actor"... 😋

[HenrikDueholm]

Hi wiebe@CARYA

Yes what you post there will indeed return the name of the object.

Both 'Get LV Class Name.vi' and 'Get LV Class Path.vi' act on the data on the wire not the type of the wire.

That is not the case with the new VIs introduced in 2020 (which are the ones my idea relates to). 'Get LabVIEW Class Parent And Member VI Information.vi' and 'Get LabVIEW Class Information.vi' act on the wire type instead of the wire data. 

TL;DR:

There is currently no runtime method to get the name of the parent of a class (or other class info) that is loaded dynamically using 'Get LV Class Default Value.vi' or 'Get LV Class Default Value by Name.vi', please fix :D.

[wiebe@CARYA]

TL;DR:

There is currently no runtime method to get the name of the parent of a class (or other class info) that is loaded dynamically using 'Get LV Class Default Value.vi' or 'Get LV Class Default Value by Name.vi', please fix :D.

But there might be a way to get the parent class of a class that is loaded dynamically without using 'Get LV Class Default Value.vi' or 'Get LV Class Default Value by Name.vi'.

I assume that if the class can be loaded, it parents must be loaded? If so, can't you use VI server to get the parent?

Why must you use 'Get LV Class Default Value.vi' or 'Get LV Class Default Value by Name.vi'?

[HenrikDueholm]

Using VI server to get the parent is only possible from the development environment. This is the method I use today to create the config files I mention in my post. From runtime you can't get this info. I had hoped that the introduction of the 'Get LabVIEW Class Parent And Member VI Information.vi' would fix this, but that was not the case.

To my knowledge using 'Get LV Class Default Value.vi' is the only way to load an unknown class on the fly. By unknown I mean a class that was not known to the application when it was built. Such as a plugin PPL with a new device driver child copied into the data folder of the application.

Application design example:

1. On application startup all children of 'Pressure driver' are identified (This is the part that is not possible from runtime... using paths from config )
2. Children of 'Pressure driver' are populated into a dropdown where their name can be used to find their path
3. Pressure driver loads from path using 'Get LV Class Default Value.vi' using above dropdown to get the path
4. Loaded class is 'LabVIEW object' is then sent 'to More Specific Class' into the parent of the pressure driver class
5. Pressure Driver parent is used throughout the application

Run time use of application design example:

1. New child of 'Pressure driver' is created and added to the data folder of the application (and we sadly also have to add the path and hierarchy info to the config file)
2. Application on startup can now detect the new child and use it without any modifications to the application. This does not require application rebuild!

If 'Get LabVIEW Class Parent And Member VI Information.vi' could be used to get info from classes loaded using 'Get LV Class Default Value.vi' we could drop the use of the config file and it'd be possible to have auto detection of new children classes!

[wiebe@CARYA]

Using VI server to get the parent is only possible from the development environment. 

I do it in my executables... But those classes don't come from a pll. I don't think it matters, if the class loads, the parents are there. It would matter for your bonus idea to get the parent without loading the class.

[HenrikDueholm]

Wow you're right!

Heh I guess I'll have to change the wording of my request then... well or just close it.

I wonder when they made that available for use from the run-time engine. It still says in the documentation that it's not available:

I'm very much looking forward to not maintaining class hierarchy config files anymore 😁.

Thanks

EDIT:

Hmm can't interact with the main post so it'll remain as it is. 

Well... the feature change would still be nice and easier way to do this... but with a working solution it's just not very important anymore.

[wiebe@CARYA]

The Parent class property is marked as not available in RTE, so is Application.LabVIEW Class.Open method (that I use to get a class reference).

Even in executables, both work just fine...

[wiebe@CARYA]

A 'officially supported' way could be this:

As long as each base class implements the Identify.vi method, this will return the base class's name.

Depending on the depth of the hierarchy, this might be a lot faster. I didn't benchmark, but there's a lot less opening and closing.

[HenrikDueholm]

TL;DR:

The 'Parent Interfaces'-property does not work in RTE and access scope(s) probably doesn't either. So VI server does not provide same features as the new 2020 VIs.

Full text:

Thanks for the input, but I'd rather not depend on the implementation of Identify.vi. Such a constraint would mean that it would only work with my own classes.

I've started my work on a Class loader module using VI server.

Turns out that the 'Parent Interfaces'-property does not work in the RTE. I also have yet to find a way to get VI access scope(s), so the idea is not so dumb after all :).

However what I'm really interested in is the hierarchy and VI server does give me that. 

Picture of current implementation:

This will not be a fast solution but it doesn't have to be as all the classes will be stored in PPLs.

This let's me easily get the class paths and I'll be able to check the PPL version or checksum to see if the stored data needs to be refreshed.

[wiebe@CARYA]

I also have yet to find a way to get VI access scope(s), 

Me neither. Haven't really looked, but the property doesn't work. It seems a bit silly as things that seem more difficult do work.

so the idea is not so dumb after all :).

I know you're not saying I did, but just to be sure, I didn't call the idea dumb.

This will not be a fast solution but it doesn't have to be as all the classes will be stored in PPLs.

When I use similar tricks repeatedly in my code, I cache the results.

Simply storing the information in a map by the name allows you to see if the information is there, and if not add it. Then it only hurts performance the first time.