02-28-2021 10:34 AM
Simple question.
I use VI Server a lot because I have developed a distributed client/server application.
Sometimes my client needs to change stuff on the server. So I get a control reference and do something like this:
In general, should I be closing those references after I use them? I like to keep the VI reference in memory, because I use it other places. But should I close the Panel and Control references when I'm done?
02-28-2021 10:48 AM - edited 02-28-2021 10:51 AM
A good place to start reading is the "exceptions" section here. There are plenty forum discussions that are worth reading, e.g. here.
02-28-2021 10:51 AM
Thank you! That was a very helpful link.
Though I wish the answer were a lot simpler. I think I need to go back through all my code now to handle all these different situations.
02-28-2021 10:53 AM
(Note that I added another link above)
03-01-2021 03:37 AM
Note that Close Reference:
+ will close an array of references. The for loop isn't needed.
+ ignores the error in. So, the sequence structure isn't needed.
+ closes the reference, not the object. So you can close the panel before closing the controls. Again, the sequence structure isn't needed.
Also:
+ the VI method Control Value.Set sets the variant value of a control by it's label... That would reduce all your code to just 1 method. However, there might be reasons to do it the hard way (although none come to mind).
10-08-2021 11:22 AM
Hi all. Thanks for your responses. I am beginning to understand this. But what about references that are generated in an event handler, as shown below? Should I be closing these refs?
10-08-2021 02:37 PM
Probably not the answer you are looking for but I would scrap using VI server all together and define a proper messaging API using TCP/IP. Using VI server you are tightly coupling your client and server. Your applications are bound to the UI (unless you are using hidden controls and indicators) which makes it much more difficult to make changes to either application. It always make it basically impossible to reuse code modules since they are dependent on controls/indicators in other applications. A well defined API makes it much easier to reuse modules, makes the system easier to understand, maintain and enhance.
10-08-2021 04:07 PM
Darren, the guy who is the poster in the 2nd link that Altenbach posted there, did a presentation a few years ago in which he revisits the "close every reference" school of thought along with a number of other LabVIEW programming stables that he disagrees with the need for. Here's a link to the presentation at the time he talks about references specifically:
https://youtu.be/pS1UBZzKl9k?t=2012
I recommend watching the section (well, I recommend watching the whole thing, actually), but one of the things he says is that closing any reference to any descendant of GObject (i.e. all controls and panels, which are what is in your example) is useless and is not needed, and is in fact a no-op in code and just takes up space.
10-09-2021 01:37 PM - edited 10-09-2021 01:38 PM
@Kyle97330 wrote:
I recommend watching the section (well, I recommend watching the whole thing, actually), but one of the things he says is that closing any reference to any descendant of GObject (i.e. all controls and panels, which are what is in your example) is useless and is not needed, and is in fact a no-op in code and just takes up space.
That's very true, but!!! When in doubt use the Close Reference!!! If it is not needed it is indeed a no-op and uses up unnecessary diagram space. But that is magnitudes less serious than a single reference not properly closed when it should be and being created repeatedly in a loop. The unnecessary used diagram space may hurt the eyes of anyone being perfectly in the know about which references need to be closed and which don't. The unclosed reference in a loop will bring your application to its knees with an out of memory error in weeks, days or sometimes even hours of uninterrupted operation.
I personally prefer an application that doesn't crash with an out of memory error above avoiding some cosmetic eye hurting. 😀