Jon Kokott

To my knowledge, this VI does not ship with LabVIEW. I wrote it myself for this thread back in '08, and it's been sitting in my "VI_Utils" folder on my computer ever since.

-D

Darren,

I find myself creating decendent classes quite often and have wanted to automate the creation of these (using vi scripiting.) Do you have any fancy private VI's that would assist me in doing this?

~Jon

The VI uses a private VI Server method that can read linkage information from the .lvclass file on disk. As a general rule, we (that is, LabVIEW R&D) password-protect any VIs that contain private functionality when we post them on public forums.

-D

Will this VI be part of LV2010 or is it allready in LV2009? -on 8.6 for now...

It looks like my attachment to this thread was lost during the LAVA site redesign. Here it is again (saved in LabVIEW 8.6).

-D

I've seen a couple of these VI's which return the class hierarchy floating around but in all cases they are locked. Where is this VI coming from? Does anyone know what it is actually doing? I really can't use a VI that is locked unless it comes with LabVIEW or is released by NI in some form.

~Jon

As it should - parents should never be child aware, children should always be parent aware.

Hey Jon: can you give us an idea of your application? Maybe we can help with a work around if we know a little more about what you're trying to do.

Basically what I'm trying to do is add classes later but allow them to be user selectable without actually adding any new code. Something like a tree control where the decendents can be viewed dynamically depending on hardware/software configurations on a given system.

This is in the context of a factory pattern and plugin architexture.

I'll try to work this out by registering new classes in a .ini file so that the main can scan who is actually out there and what is available for runtime purposes.

we'll see how this goes, I'm getting a little experimental now...

~Jon

There is no way to accomplish what you are requesting. A parent class is saved without any knowledge of its children. There may be infinite children on your disk, out on the network, anywhere. Some subset of those children may currently be in memory. Those are the only children that a parent knows about, and since those are already loaded, they're of no help to you.

A class does know who its parent is. When the class loads into memory, it automatically loads its parent class, so you don't have to dynamically load that.

Once in memory, a class can be asked for a list of all its children *in the editor environment*. You cannot do this in the runtime engine.

Ok, perhaps a work around of registering all the classes and their hierarchy in an initialization step (from .ini file?) will do the trick then. At any rate, it sounds like I MUST load the parent of a particular target class before loading that target or labview will spit out errors.

~Jon

Hi Jon,

You'll have to separate this in two approaches: ancestors and descendants.

For ancestors, there is a private method for getting the ancestor class. Running it recursively will get you all the ancestors. You can cut the chase by installing this API. There are methods found in the installed palette for doing what you want.

For descendants, the parent doesn't have any record if a class is its descendant. So you've got to typecast the potential child to its alleged parent class and see if it throws you an error.

I've run the toolkit, but it does not appear to retrieve descendent or child classes. The List_Ancestor_class.vi only lists the ancestors of my target class, and the original class I gave as a target.

Here is the code:

Is there any way to read the class hierarchy at runtime in LVOOP?

Given a class, I want to be able to know who its parent is and what decendents are valid for that class. Specifically I will be needing the paths of the .lvclass eventually so that I can dynamically instantiate the decendent/parent classes.

~Jon

Hi Jon,

Time has passed and LabVIEW API has been officially released by NI, see here.

Thanks, installed activated and working properly.

~Jon

Editing thie Labview.ini file doesn't seem to be working for me (I'm not seeing the private methods for the block diagram.) Is there anything else I need to do to enable VI scripting?

Using Labview 8.6, edited the "C:\Program Files\National Instruments\LabVIEW 8.6\LabVIEW.ini"

Addtionally I've tried to enforce launching using that ini file (it should be the default anyway...)

from command Prompt:

G:\>"%ProgramFiles%\National Instruments\LabVIEW 8.6\LabVIEW.exe" -pref "%CURRENTDIR%\BPR 2-12-2010.ini"

Are there any Labview.ini preferences that would conflict with this one? I've edited that file a number of times in the past.

~Jon

Attached Labview.ini file (renamed labview.txt)

LabVIEW.txt