Close a passed reference in a subVI?

[george seifert]

If I pass a reference to a subVI and close it there is it really closed or do I need to close it in the calling VI?

George

[ned]

If I pass a reference to a subVI and close it there is it really closed or do I need to close it in the calling VI?

George

It's really closed, like with a queue or notifier.

[Ton Plomp]

It's closed, if it's closable (for instance you cannot close a ref to a FP or a control, that's just basically a NoOp.

(or do you have evidence it's not closed?)

Ton

[Darren]

Stylistically, I almost never close a passed-in reference in a subVI. I always close it in the same VI that opened/generated it. That way I don't have to worry about a reference that I think is valid actually being invalid because it was closed in a subVI somewhere beforehand.

-D

[george seifert]

It's closed, if it's closable (for instance you cannot close a ref to a FP or a control, that's just basically a NoOp.

(or do you have evidence it's not closed?)

Ton

No real evidence that it's not closed. Just trying to track down some flaky behavior and closing that reference raised a question.

George

[PaulG.]

Stylistically, I almost never close a passed-in reference in a subVI. I always close it in the same VI that opened/generated it. That way I don't have to worry about a reference that I think is valid actually being invalid because it was closed in a subVI somewhere beforehand.

-D

I'm the same way but I think there is more to doing it that way than just "style". I don't think I've ever seen an application where a reference was closed in a subvi. It just doesn't seem to make much sense. To me that would be a good example of code obfuscation.

[george seifert]

I don't think I've ever seen an application where a reference was closed in a subvi. It just doesn't seem to make much sense. To me that would be a good example of code obfuscation.

OK, you've convinced me. I'll move it out of the subVI. It seemed to make sense in my situation, but I can see where it could lead to problems.

George

[Aristos Queue]

OK, you've convinced me. I'll move it out of the subVI. It seemed to make sense in my situation, but I can see where it could lead to problems.

I've seen it in cases where the subVI itself was named "Close", but there was some other work to be done along the way. It should actually be common when using DVRs with classes since the only way you *can* close the reference is in a subVI if the class options are set to restrict it (which they are by default).

[Yair]

Note that it also depends on your definition of "reference". Closing a reference will release that reference, but will not necessarily destroy the resource it's pointing to (e.g. if you obtained several references to a queue by name).

[mje]

Indeed, common practice is to manage the closing of a reference from the same scope which opened it. I follow this in *any* programming language as best I can.

AQ mentioned class/DVRs often need to break this rule. I've also found the need to break it when making asynchronous calls where the caller does not wait for a return. As is always the case, you can't really define a steadfast rule.

[Aristos Queue]

Indeed, common practice is to manage the closing of a reference from the same scope which opened it. I follow this in *any* programming language as best I can.

It matters what the "Open" function looks like. Again, with DVRs and classes, the Open function is also a subVI, and, in line with what mje writes, I would expect that Open.VI and Close.VI would both be called in the same scope. Thus I wouldn't see it as an exception to "close what you open in the same scope" so much as "parallel operations should have equal depth" --- if your close is in a subVI, your open should be as well, and all the work done in that open should be undone in that close.