Destructor LabVIEW

[JohanHoltby]

It would be nice to have a callback to register when a VI is unloaded from memory.

I normaly use FGV pattern to encapsulate my instruments. I would be neet to register a "close" VI when you initilize the FGV VI and then when the FGV is unloaded the close VI closes the refereances (and transform the instrument to a safe state).

To conclude I want a similar way to  C++ destructor.

[Manzolli]

I'm not an expert in this subject, but looks like to get what you need you have to jump from FGV to OO.

[JohanHoltby]

Sounds intresting. I have not diged in to OO in LabVIEW. But is tehere automatic ways to destruct the LabVIEW class when it's unloaded?

[Manzolli]

Me too, I did not played yet with OOP (forgot the P ). Since FGV has some similarity with OOP, properties (values) in Shift Registers and methods (functions) in each case of the FGV), OOP may have the characteristics you need.

For a start you can have some information here Introduction to OOP

[JohanHoltby]

Looked some int to it and it seams like LabVIEW don't suport destructors: http://www.viewpointusa.com/newsletter/2012_Jul/mainarticle_2012_Jul.php

Thank you for the tip any way and feel free prove me wrong on the non exeistance of destructors which are called upon unloading of a class. I't seems to be wyas to implement destructors which can be called to unload stuf but then I have the same fuctionality in a FGV.

Once again thank you for the tip!

[Manzolli]

How about creating an option, lets say "destroy", in FGV that does finishes the "work". Additionally you can use Request Deallocation to minimize the memory problem. After "destroy" is called, a shift register could be set to inform, in a future call to the FGV, that the instrument is not available anymore, returning an user error code.

There are three main reasons that still keep away from OOP:

1. Not really needed for a specific problem;
2. Some criticism about the way NI implemented it;
3. Can do anything (until now) without OOP.

Until a task really needs to be done using OOP I will stay using FVG and other programming techniques.

Thank you too, I'm learning too. I hope one day I became a day by day OOP programmer.

[JohanHoltby]

Thankyou for your thoughts.

The point is that I don't want the teststad sequnce person to think about initliziation (which i today do using a initilize boolean shiftregister) but also not need to buther about closing refereances. The last part is what I'm looking for. Memmory is not a problem for my aplication. It's ease of use. 

[tst]

I think the big problem with destructors for your specific case is that the destructor code would have to be part of the FGV itself (since presumably all the references are in shift registers inside the FGV), which is a bit of an issue, because that requires specifying a special way to run the VI in a particular case.

In general, LV already closes references when VIs go out of scope, but that won't apply to special cleanup you might have to do with your instruments.

One thing you could do is monitor the Application Instance Close event somewhere react to that (e.g. in a VI you launch when initializing), but that would only work when ending an EXE and would therefore only really be relevant there.

Another option is to launch a VI which will monitor the execution state of the VI which called the FGV first and clean up when that goes idle, but that VI going idle would generally cause LV to clean up the references in the FGV on its own and it's likely you won't be able to communicate at that point.

The issue of scope and data flow is such that this seems difficult.

[Dennis_Knutson]

I think you can simply place the close function in your cleanup step in TestStand. That's what's it there for.

[JohanHoltby]

I understand that. But what I have run in to is that when amny different people whit diferent level of knowlage is developing in maunal mode in teststand the cleanups steps are somties just skipped in total to avoid losing power and reseting the system. The way i takel that is to devid the cleanup step in to two steps: one step turinging every thing off and releasing locks and one step for releasing all reference. I use lasy initalization usign av FGV as stade above.

This is however partly disobaying one important coding paradigm: encapsulation. That is the reason for my sugestion.

However thank you for your thought!

[AristosQueue (NI)]

There's nothing in LV today that will achieve the effect JohanHoltby is requesting. Well, nothing published, anyway. I know a magic trick to hook into the VI execution system, but I wouldn't recommend that to any user for production code.

This is a good request, one I have had myself at various times. I'll add my kudos.