Question about Write Panel to INI__ogtk.vi

[kgaliano]

Good afternoon,

 

I have a question regarding the subVI called "Write Panel to INI__ogtk.vi" in Labview version 2012. It seems like the input parameter "VI ref" is a reference that is not closed by this VI (specifically where the property node used to obtain the VI name is located). I was wondering if this can cause a memory leak?

 

Thank you.

[drjdpowell]

The VI ref was created by the calling code, and the calling code is responsible for closing it if/when it needs closing.  If I were updating this VI, I might add a “VI ref out†output to visually prompt the developer to deal with the ref.

[hooovahh]

Yup, the only potential memory leak is if this function opened a new VI reference, but didn't close it, or return it to be closed.  The way the function works now, it will take a reference it assumes is already opened and then not close it.  Generally if you open a reference, it should be closed in the same place it is opened.  But honestly most of the time I use that function it is with a This VI reference which doesn't need to be closed anyway.

[kgaliano]

Thank you for your replies. Does this imply that, in general, "This VI" references do not need to be closed? So I am guessing that memory leaks typically arise from other references (e.g., control refnums, indicators, files, etc.)?

[drjdpowell]

Does this imply that, in general, "This VI" references do not need to be closed? So I am guessing that memory leaks typically arise from other references (e.g., control refnums, indicators, files, etc.)?

 

Some refs are static; they always exist and you are neither creating or destroying them.  â€œThis VI†and control refs are of this type.   “Closing†these refs is a no-op.  Other refs are both dynamically created and involve holding resources open of some kind (like an open file, or a Queue or something).  Here is where one worries about ‘memory leaks’.  

[hooovahh]

"This" is a term I've heard NI use to refer to these types of references.  If a reference is a This reference (like the This VI, or This Application, or This Control) then yes closing it is a no-op.  The reference simply cannot be closed because it is being used.  One way to know if your reference is a This or not, is to cast it to a U32 and look at the refnum.  If the number changes with each run of your VI then it is a new reference and should be closed.  If it is the same then there isn't a need to close it.  I've also done a test where I run the VI using the run continuous and see if the memory in task manager increases.  If it doesn't then what ever references I'm opening and is enough for a stable system.

[Darren]

I talk about which references should be closed vs. which ones you don't have to worry about closing in my Brainless LabVIEW presentation.

[kgaliano]

Thank you for your explanations.

[ShaunR]

I talk about which references should be closed vs. which ones you don't have to worry about closing in my Brainless LabVIEW presentation.

I was emphatically with you right up until the "train tracks" (my OCD prevents your version and there are genuine reasons for pass-through for optimizations) and palettes.(time and motion studies on placing primitives is ridiculous - you can make mistakes faster? ).

 

Nice to see a fellow heathen picking holes in accepted dogma. Beginning to think I was the only one