list children classes?

[ensegre]

How can I, given a parent class object, get programmatically an array of names of its direct children? The information is available in the class Hierarchy view, so I thought that some secret vi buried in vi.lib/Utility/LVClass or such might have come to play, but found none.

TIA, Enrico

[Neil Pate]

I know nothing about the internals of LabVIEW on this one, but would be a bit surprised if the parents knew about their children, it is more likely to be the other way around surely?

 

At runtime you can inject new child classes, so surely this means the parent must have zero knowledge of children?

[ensegre]

At runtime you can inject new child classes,

off topic and bear me for my ignorance, but how do you do that in LV? Plugin libraries (which I never confronted with)?

Anyway, even in that situation, wouldn't it still be meaningful to ask the list of currently known children?

[shoneill]

I think we're talking about edit-time information, not run-time, right?

 

Parents knowing about their children at run-time sounds wrong.

[ensegre]

how badly would you roll your eyes, if I ask why wrong at runtime?

[shoneill]

Why exactly does your class need to know about existing ancestors at run-time?  It sounds like a design problem, not a code problem.

[ensegre]

It may well be. Suppose I have a class Devices to which I add incrementally (coding more, plugins are yet over my head) children drivers for specific instruments. I want to display a list of those implemented so far / offer the user to choose which instrument to use for a task among those available, and such.

[shoneill]

Well if you don't have a plug-in architecture working yet (which would be one way to solve his problem) you need to have your classes included statically somewhere in your code.

 

Why not make an array of your implemented classes and simply call an "ID" method on them returning their IDs which may or may not be different from their names on disk.

 

How are you managing all of your different classes at the moment within your program?

[ensegre]

Well if you don't have a plug-in architecture working yet (which would be one way to solve his problem) you need to have your classes included statically somewhere in your code.

 

Why not make an array of your implemented classes and simply call an "ID" method on them returning their IDs which may or may not be different from their names on disk.

 

Precisely what I did. Not even an ID method, just Get LV Class Name.vi for now, but that's the idea. I thought there must have been a smarter way, like this I would have to maintain the static array every time I create a new class.

 

[Ok, the question was purely academic: I have so far just three such classes and they are not supposed to increase any soon. Even.]

 

 

How are you managing all of your different classes at the moment within your program?

In what sense managing?

[shoneill]

I meant managing in the sense of "how does your program know when to use which class?".

 

Given the absence of a factory pattern, you will NEED to have this array maintained statically.  These are essentially the two options available.  One is static, the other is dynamic.

[ensegre]

I meant managing in the sense of "how does your program know when to use which class?".

 

Picking the desired element of that static array.

 

I guess I need to educate myself more about the factory pattern in future. Thx for the answer!

[QueueYueue]

Two ways to do what the OP is asking.
 

1. VI Server world:

Children have a static link to their parents and Parents have a dynamic link to their children. This means that once a class is loaded into memory, the parent knows about the child. According to the documentation this will NOT work in the runtime environment, but i've used this several times when making IDE Tools.

 

2. Runtime Reflection:

The following code will also give you an array of all of the children loaded in memory, but this time it uses less VI Server so it will work in the runtime environment. I use this when using a plugin architecture. I've not done a lot of performance testing with it, but on a medium-ish size project (one with ~150 classes) it only takes about 50 ms to run, so it's worked well for me so far.

 

Having given you those solutions, I still think your best bet is to use a statically defined array. This will ensure things are loaded into memory when their needed and such. My solutions really only become worth it once you're dynamically loading classes.

[ensegre]

Impressed. I remark that 1 gives only first children, while 2 all descendants. At least with a 3 generation hierarchy of mine which I tested.

[smithd]

As for your other question about plugins, theres a few links I'll put below but you should ask yourself these questions:

Do you really need to do this?

...I mean really, are you sure?

......No really, its not fun.

 

Ok so if you really do decide to do this, theres a few things that would come in handy:

https://ekerry.wordpress.com/2012/01/24/created-single-file-object-oriented-plugins-for-use-with-a-labview-executable/

https://decibel.ni.com/content/groups/large-labview-application-development/blog/2011/05/08/an-approach-to-managing-plugins-in-a-labview-application

https://decibel.ni.com/content/docs/DOC-21441

 

Depending on how many plugins you have and how many platforms you need to support and how many labview versions you support (Versions*OS*plugins=lots??) you should look into using a build server like jenkins.

 

Finally, as for the actual code you might find this handy

https://github.com/NISystemsEngineering/CEF/tree/master/Trunk/Configuration%20Framework/class%20discovery%20singleton

its an FGV which locates plugins on disk or in memory, removes duplicates and allows you to load classes by an unqualified or qualified name (assuming they're unique). Its not particularly complex but it provides all the little wrapper functions we needed.

[Ben van Seggelen]

I did it like this, I do not know if this was an option back in LV2014

[Rolf Kalbermatter]

On 9/8/2021 at 10:50 AM, Ben van Seggelen said:

I did it like this, I do not know if this was an option back in LV2014

It's essentially the same as what QueueYueue posted. And it has the same problem, it won't work at runtime.

"LVClass.Open" is not available in Runtime and Realtime (Library: Get Ref by Qualified Name is available but not remote executable, but typecasting to LVClass won't work since the Runtime and Realtime does not support that VI server class).

"ChildrenInMemory" is not available in Runtime and Realtime

All LVClass properties and methods are not available in Runtime and Realtime