LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Determine if lvclass is in heirarchy of opened VI ref

In short, I want to be able to determine if using the Open VI Reference node causes a lvclass to get loaded into memory as well.

 

I know I'd be able to check the App.AllVIs property and crawl through the list looking for .lvclass namespaces and compare to the list before opening the root VI ref; I'm just curious if there's a less brute-force method.

 

I've got a plugin architecture that I'm looking to expand to include plugins that use LVOOP which will limit some of the available features for the plugins and I'd like to control these features at the plugin manager level. (lvclass files cannot be unloaded from memory).

0 Kudos
Message 1 of 8
(1,761 Views)

If the class gets loaded into memory for any reason I would expect it to show up on the class hierarchy view. I'm not 100% sure on that though, just a thought.

Matt J | National Instruments | CLA

GCentral
0 Kudos
Message 2 of 8
(1,729 Views)

Is that available programmatically though?

0 Kudos
Message 3 of 8
(1,715 Views)

What about the application class property "VIs in memory" makes you want to avoid it?

 

Why dismiss this approach when it works?

0 Kudos
Message 4 of 8
(1,707 Views)
Already mentioned that.
0 Kudos
Message 5 of 8
(1,698 Views)

Does it not work?

0 Kudos
Message 6 of 8
(1,692 Views)

Maybe you can try opening a reference to the .lvclass object by wiring up only a string (no path).  IIRC, this will error out if it is not in memory.

0 Kudos
Message 7 of 8
(1,691 Views)

It's a plugin system, I don't know what classes there are ahead of time; the whole point is to break dependencies between modules until run time and even then I'm using a messaging system so that modules can communicate through the plugin manager and only need to know the message IDs to communicate on.

0 Kudos
Message 8 of 8
(1,677 Views)