What's wrong with a "regular" global in this case? AND WIl ActiveX objects stored in functional globals remain valid (when used in an executable)?

Question

I've written a plugin layer for a LV executable.  When this layer makes a call to the plugins' initialization functions, I want each plugin library to be able to initialize and maintain its own global memory (where things like VISA resource names or ActiveX objects are stored).  However, I've found that I can't manage to keep my global VIs "alive."  I'm inclined to switch to functional globals, but I suspect that this will be a problem for things like ActiveX objects (that in this particular case reference a CAN interface).  I believe that the functional global will indeed store the object from run to run, it's just that I'm somehow disinclined to think that the object will remain valid.  I think you'll have to re-initialize it.  Can anyone speak for or against this hunch?  (If you can't tell, I'm trying to avoid building a whole little test executable just to debug this problem.)
I suppose the more profound question is "Why don't the globals stay in memory?"  I'm attaching an image of what the application layer that calls the plugins' intializations looks like.  Next I'm attaching an example of an actual initialization routine.  You'll notice that I've even gone so far as to explicitly open the ref to the global VI that I want to keep in memory.  Then I just leave it there dangling - but it still gets dropped!  In my mind I shouldn't even have to do this, since the dynamically-called subVI "MC_CMO Init.vi" actually initializes the globals and runs with AutoDisposeRef = False. 
Lastly, this is my first-ever attempt at writting plugin software.  So if you look at my code and have any criticisms/pointers, I'll greatly appreciate them.
Thanks in advance,
Nick
"You keep using that word. I do not think it means what you think it means." - Inigo Montoya
Attachments:
AppLayer.JPG ‏60 KB
InitPlugin.JPG ‏103 KB

Answer 1

I am not sure if I follow you completely on your work-around.
Everything I have to say on this topic is based on obesrvations and threads I have read on Info-LabVIEW. Therefore it is subject to corecttion by those who know better.
LV is smart enough to know when "something" that had been opened, can be closed. It is not perfect.
If for instance you open a VISA refnum and pass the refnum  to a LV2 AS A REFNUM the refnum in the LV2 stay alive as long as the VI's are running.
If you start another VI that uses the LV2 to fetch the refnum, it should get a valid ref as long as it starts before the first goes idle.
You then be able to work with refnum usign the VI launched second as long as stays active.
I often create action engine that can be invoked where required throughout an application. If the action engines get a ref in one state (like init) and use it another, I will generally write a "tester" that calls the action engine action to test the engine. In this case, my "tester" stays live and it keeps the ref's fresh.
I suspect if you tried to trick LV you could. If you type cast the ref nums to I32 and stored those in a LV2, I could see how LV could loose track of the resource sharing, but that is something I would avoid.
So I encourage you to do some experimenting with keeping track of who's running when to see if your work-around will work.
If you think you understand it better than I explained it, please post.
Trying to help,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction