Jump to content

Close a passed reference in a subVI?


Recommended Posts

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

Link to comment

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.

Link to comment

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

Link to comment
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).
  • Like 1
Link to comment

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).

Link to comment

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.

Link to comment

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.
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.