Remove Control from Memory

[Bob_Schor]

I've written a VI using VI Scripting that creates an Enum based on an array of Names.  For example, if I have an array with "Initialize", "Process", "Exit", I can create a control "State.ctl" consisting of an Enum with these values.

The trouble comes from wanting to "redo" (i.e. re-run) this VI, say because I want to add another state, "Clean-up".  If the original VI is in memory (because I'm developing code, and have used it), when I run my Create Enum script, it gives Error 1357 when it tries to write State.ctl, saying it is already in memory.  One solution is to exit LabVIEW, restart, and run fresh, with the control-to-be-overwritten not (yet) in memory. 

Is there a way to Have My Cake and Eat It, Too?  Can I write a VI that will inquire if State.ctl is in memory (for example, by wiring just the name to an Open VI Reference and seeing if there is no error, which means it's in memory) and then purging it from memory?  If so, I could avoid the 1357 error.

BS 

[DFGray]

The All VIs in Memory App property will tell you whether or not the control is still in memory.  Alternately, you can try opening it with just the name instead of a full path.  If it is in memory, the open will succeed.  If the open succeeds, just add the new item.  If not, create the whole thing.

Closing something in memory is tricky, since LabVIEW has all sorts of optimizations to keep things in memory and so avoid reloading.  You would need to ensure all callees are closed, at the least.  You could do this by recursively calling the VI property Caller's Names until you get to the top.  Close everything and it should eventually go out of memory.

[Bob_Schor]

Closing the callers was the "missing piece".  Here is the routine.  If it is not in memory, it throws an error which I clear in the Error case (not shown).  Otherwise, I enumerate its callers, recursively call itself to close each of the callers, then open and close the routine (if it isn't open, trying to close it will throw an error).

Incidently, while posting this, I thought I'd be "clever" and call this VI on itself -- a bad idea, as it starts an infinite recursive chain ...