09-21-2016 08:56 AM
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).
09-21-2016 08:01 PM
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.
09-22-2016 01:53 AM
Is that available programmatically though?
09-22-2016 06:48 AM - edited 09-22-2016 06:49 AM
What about the application class property "VIs in memory" makes you want to avoid it?
Why dismiss this approach when it works?
09-22-2016 06:50 AM
09-22-2016 07:01 AM
Does it not work?
09-22-2016 07:02 AM
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.
09-22-2016 10:35 AM
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.