LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Which references need to be "Closed"?

Hi all,
      Today I was poking-around in "Snd Play Wave File.vi" (LV 7.1) and noticed that a VI reference is opened but not closed.  Maybe it doesn't matter, but there's been a lot of talk about why references must always be closed - and I'm sure some should be - but which?
 
To date, my rule-of-thumb has been to Close only when somthing's been created (by me.)  An example of references that shouldn't (I don't think) need to be closed are in the "Controls" array-of-references property of a cluster.  But sometimes I'm not surewhether I created anything or not.  It probably can't hurt to close everything, but is it necessary?  What about when a property node is used and exposes a bunch of attributes - including a read-only reference, but the reference isn't wired?  Is this a mistake?
 
Must we hunt-down every stray reference and terminate the poor things?
 
Cheers
 

Message Edited by Dynamik on 01-05-2006 09:00 PM

When they give imbeciles handicap-parking, I won't have so far to walk!
Message 1 of 33
(17,598 Views)
Do not worry about closing EVERY preferences.
Just try to close it all if you need not to read this preference again while your program is still runing.
I think that the problems with unclosed preferences may be apear in large proglam with alot of VIs or many itterations which trying to open alot of preferences. 
 
LabVIEW 7.1
0 Kudos
Message 2 of 33
(17,578 Views)

Don't forget that references for external applications, such as ActiveX and .NET references must be closed explicitly. Other than that, Leonid's response is very appropriate. Users should only see memory or performance issues in large applications or applications with references opened in loops with many expected iterations if they don't explicitly close their references.

You might also be careful about your memory management when targeting a real-time device, since they typically have much less memory than desktop PCs, and a memory overflow will cause the entire target to reboot.

Jarrod S.
National Instruments
0 Kudos
Message 3 of 33
(17,538 Views)
if you don't close the reference, even when you close the application, the process will hang around (you can see the process when you look into Task Manager (Ctrl Alt Del) -> Processes.  I was using ActiveX with Excel last time, and didn't know that I need to close the reference, and I ended up having many excel processes running in the background even though they were not used....
0 Kudos
Message 4 of 33
(17,528 Views)

FWIW, I have noticed that, at least in LabVIEW v7.1.1, when I get a reference from a property node of some object, the help window for that reference property sometimes says that the the reference must be closed when you are finished using it.

I don't know if that means that the ones that don't say anything don't require closing...

For example, the help for the "Panel" reference of a "VI" property node doesn't say anything about closing being required.
The help for the "OwingVI" reference of a "Pnl" property node (wired to the aforementioned "Panel" reference) does say "Close this reference when you are finished using it."
0 Kudos
Message 5 of 33
(17,516 Views)

Here's my take on closing references.  My #1 rule regarding references is to always close them, no matter where they came from.  I have two (hopefully obvious) exceptions to this rule...I don't close static references (like Control Reference, This VI, This App, etc.), and I don't close the reference output coming from an implicit App or VI property/invoke node (you know, the kind where you don't wire the reference input, and thus they refer to the current App or VI).  Everything else I close.

That being said...

There are some references (as of LabVIEW 7.0 and later, I think) that are ok to not close because LabVIEW will automatically close them for you once your VI goes idle (i.e. it stops running, and any VIs that call it stop running).  Primarily, these references come from property nodes, i.e. the "Controls[]" property of the Panel class.  If you get an array of controls on the panel via this method, you will be ok if you don't close them all, because they'll be automatically closed once the VI goes idle.  Even if you get this array in a loop, and you don't close the references, you should be ok, because the property node will return the same references each iteration of the loop, i.e. it won't return a new reference to the same object every iteration.  Again, it didn't always behave this way, but it has since (I think) LabVIEW 7.0...maybe even earlier.

However, for pretty much all other kinds of references, you need to close them to avoid leaks.  This includes any VI reference, like those you obtain from an Open VI Reference, or even those VI references obtained from property nodes (like the example given in the previous post).  Also, *any* reference you get for ActiveX, .NET, or some other non-VI Server interface, needs to be closed.

So, since there are some references that *must* be closed to avoid leaks, and there are some references where it's ok to not close them, it's best to be safe and always close everything (see my #1 rule above).

-D

Message Edited by Darren on 01-06-2006 03:03 PM

Message 6 of 33
(17,503 Views)

Thanks for all the pointers! Smiley Very Happy


@Dynamik wrote:
... there's been a lot of talk about why references must always be closed - and I'm sure some should be - but which?

To summarize(/paraphrase & infer) for posterity,
General-rule: Close any/all references - when they're no longer needed.
ActiveX/.NET: ALWAYS CLOSE ActiveX/.NET references (Thanks Jarrod, Elsa & Darren)
VI-Server: For VI-Server references, see HELP for the specific Property-node - (Thanks Warren!)
VI-Server: VI-Server references close automatically when application exits. (Thanks Loenid, Jarrod & Darren) 
VI-Server: VI-Server "Static" references (this App, this VI, Control-references) allocate memory (once).  If memory's an issue, close them, otherwise they close automatically when Application exits. (Thanks ALL)
 
According to these rules, and in the case of my example, memory IS allocated by "Snd Play Wave File.vi", but only once - no matter how many times it's called.  That memory is de-allocated when the Top-level VI finishes executing.
In the case of the "Controls-array" associated with a panel, or cluster, it's still not clear whether there's anything to 'close" - and HELP is silent Smiley Wink.
Does wiring to the array-of-references mean memory suddenly gets allocated for every reference? Smiley Surprised This may sound silly, but if true, then all elements ought to be closed - especially if memory is an issue.
 
I'm grateful to the help so far, but am left with the burning question (maybe it's just my stomach):
Are there kinds of [VI-server] references for which "closing" has no effect?
Put differently: is memory allocated for some "object", at least once, for any reference that is used?
 
Cheers!                                
When they give imbeciles handicap-parking, I won't have so far to walk!
Message 7 of 33
(17,480 Views)

Hi again,

Yes, the Close Reference function is a no-op on those references I mentioned that the VI will close for you when it goes idle.  You can see this for yourself with a simple VI where you get the Control reference array for the panel, index off a control, read a property of the control, close the control reference, use the *same* reference wire you just closed, and read another property of the control.  The property will read just fine, and you will not get an error out of the property node (like you normally would if you had an invalid reference)...this is because the Close Reference function did not do anything because this was one of those special references that the VI will "clean up" when it goes idle.  I have attached a screenshot of a VI that demonstrates this.

Hope this clears things up a little bit.  Remember my rule though, always close the references, even if they're the kind that don't really get closed.  It's just good coding practice.

-D

0 Kudos
Message 8 of 33
(17,473 Views)

Hi Darren,

      I truly appreciate your posts - and read them carefully.  That's a powerful observation about closing Controls[] references having no effect!  Now I know never to use a for-loop to be sure all the Controls[] references are closed. Smiley Happy

But in the context of this thread, the following statements might be slightly misleading Smiley Tongue


I don't close static references (like Control Reference, This VI, This App, etc.)

... the Close Reference function did not do anything [to a Controls[] reference] because this was one of those special references that the VI will "clean up" when it goes idle.


Apparently, Closing VI, ("Owning VI") and App references is effective - as memory (apparently) is allocated&deallocated as a consequence of their use.
It seems Controls[] references don't need to be closed, because there's nothing to clean up (not because they're cleaned-up automatically.) 
The distinction here is that use of some references may cause memory allocation, others not.
 

Remember my rule though, always close the references, even if they're the kind that don't really get closed.  It's just good coding practice.

I agree, no harm to close it - when one doesn't know what needs to be closed.  But, maybe, better to omit extraneous, usless operations?

So the question remains, how to know what's useless, and what's not.  Warren's observation is particularly relevent here - truth may be in "The Manual". Smiley Very Happy

.

Message Edited by Dynamik on 01-07-2006 01:19 AM

When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 9 of 33
(17,469 Views)
Hi,

This is my experience using de Controls[] property:

I made an application where I used the Controls[] property of a cluster in a for loop to change the properties of some cluster elements. But everytime the for loop was called my application runned slower and slower and slower....

I also read in the manual that it wasn't necessary to close control references, but after putting in a Close reference function in the for loop (like Darren did in his example), the problem was solved!!

So I agree with's Darren's rule!!

BJK
Message 10 of 33
(17,445 Views)