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).
What about the application class property "VIs in memory" makes you want to avoid it?
Why dismiss this approach when it works?
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.
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.