Do I have to close all my references?

[Fibo]

I have a VI that opens up another VI and allows me to control the other VI by opening references to the controls and using property nodes to mess with the controls.... when I'm done, I close my main VI reference, do I have to close the references to all the controls too? What happens if I don't?

[aeastet]

Not if they are contained within LabVIEW. You would have to if a different application owns then say MS Excel. If you opened references for MS Excel then you would have to close all of then to have the application close out of memory.

LabVIEW silently closes reference that are contain within the LabVIEW application. This would include references to vi's and controls inside LabVIEW.

[JÞB]

Back in this thread the learned Ben schooled me a bit on this subject.  Although you can never go wrong by closing the referance (and IT IS a good programming practice ala the style guide- definately DO close them on a CLD exam  )

But it appears that LabVIEW (so simple a caveman can do it) is pretty forgiving of programming practices that may be less than professional.  So, if you don't the cleanup happens later when the OS gets a break to get around to it.  It is actually more important to NOT HOG the CPU than to expressly close referances to LabVIEW objects.

[Michael Ludwig]

You don't need to close references to vis, though you should close references to vis and OS objects (activeX, etc) for memory management purposes and clarity of programming. I never thought of closing references to controls, to be honest. Can you even do that?

And a little word of warning from experience: even though wiring references to controls into sub-vis is very neat and convenient, it is _very difficult_ to debug, and i would only do so when necessary. There is (almost) nothing worse than figuring out that your apparently crazy boolean was being set by some rogue sub-vi five levels down!

[JÞB]

---

@Michael Ludwig wrote:

You don't need to close references to vis, though you should close references to vis and OS objects (activeX, etc) for memory management purposes and clarity of programming. I never thought of closing references to controls, to be honest. Can you even do that?

And a little word of warning from experience: even though wiring references to controls into sub-vis is very neat and convenient, it is _very difficult_ to debug, and i would only do so when necessary. There is (almost) nothing worse than figuring out that your apparently crazy boolean was being set by some rogue sub-vi five levels down!

---

Yes you CAN close control referances

There is (almost) nothing worse than figuring out that your apparently crazy boolean was being set by some rogue sub-vi five levels down!

This is why you pass the ref to an action engine on a shift register- and only access the variable through the AE. 

[Michael Ludwig]

I've never put references in an AE; i'll have to think about that. But would that actually address my gripe? as you could still access the AE from just about anywhere and set controls way outside of the vi on whose front panel they are. Do you have AEs only for controls or do you mix data with ctrl refs? Do you then close those controls in the AE for completeness' sake or don't you bother?

I guess the solution is to have sub-vis (and AEs) dedicated to the user interface, so you (actually: the next coder coming after you) can easily know what vis are likely to be setting your controls. It's a matter of clearly distinguishing the UI logic from the Application/business/test logic -- even in subvis and AEs.

but i'm a bit off-topic now so i'll stop.

[Neil.Pate]

You do not need to bother closing references to FP controls. When you "get" a reference to these controls, it is not really dynamically allocated. i.e. between runs of the VI you can stop and start and the reference is still valid. This is actually quite handy in lots of circumstances. So if you are passing control refs down to subVIs, even if you do "close" the ref in the subVI you are not really closing the reference.

Any references that are dynamically allocated (ActiveX and others as mentioned by others) you definitely should close. In these instances it is often best to try and get the reference only once, use it as much as you need to, and then close it when you are done. These are the kinds of refs that lead to slow memory leaks. The key here is that every time you run the VI or bit of code, there is a good chance that if you probe the wire you will get a unique reference every time the ref is obtained, this is a big clue that it should probably be closed when you are done with it.

[JÞB]

---

@Michael Ludwig wrote:

I've never put references in an AE; i'll have to think about that. But would that actually address my gripe? as you could still access the AE from just about anywhere and set controls way outside of the vi on whose front panel they are. Do you have AEs only for controls or do you mix data with ctrl refs? Do you then close those controls in the AE for completeness' sake or don't you bother?

I guess the solution is to have sub-vis (and AEs) dedicated to the user interface, so you (actually: the next coder coming after you) can easily know what vis are likely to be setting your controls. It's a matter of clearly distinguishing the UI logic from the Application/business/test logic -- even in subvis and AEs.

but i'm a bit off-topic now so i'll stop.

---

Granted- just a bit off topic so with appologies to the OP-

Yes I DO! OFTEN for medium to large projects.  As an example I may have a Table on the main UI the contents of said "Table" are displayed to the operator and contain a columns of data "Step Name", "Limits", "Units","Comparison" etc.  Some of these columns populate from a configuration file (determinied by test to run from user input) and some of them (like measuremnts and results) are populated by the test execution.  My UI is generally an event driven producer that enqueues commands to the "guts" of the test.  So I create an AE with modes (Init, Clear Table, Add steps, Add results, Get active row, Set active row, Read All, and Close).  The UI BD calls the Init and Close modes.  Init takes a Control referance to the table and places it on a USR After this point I can call the AE from anywhere in my system and take any action on the table.  (I could even create events on the UI BD when the value updates and I DO do this with other controls on my UI)  Th AE is accessed from the Display State machine (report generator and updator of several UI objects) , the test engine(handles breaks, conditional breaks and determins which file to load the test steps from etc...) from the Test State machine (really does the data collection and I/O) and of course I could add additional modules. 

TWO Caveats though- don't access the object from anywhere else- or the referance on the SR will go stale.

don't use this with objects on tab controls!  when the user changes the displayed tab the referance on the shift register in the AE goes stale (I suspect the "visable" property gets changed in the backround.) 

As far as debugging- IF you place the call chain primitive on the BD and an indicator on the FP any combination of contitional probes on the value of the control will give you the EXACT location where you made an "insane" write to your boolean-  Trust me, Debug is greatly aided by this even if its 20 levels down-

[Fibo]

Thanks for all the replies!

[Matt_W1]

 I generally close all references that aren't placed on the BD as constants (I count Static VI references as constant). I once had to hunt done a memory leak for a couple of days it turned out that the "Owning VI" property on front panel objects returns a dynamic reference and must be closed (This is also true of references from open VI reference). The close reference node can close an array of references, which can make things easier.