Bug in Design pattern in untested versions 1.3.6

[jonasmaki]

When adding a design pattern of "Active Object: Dynamic Events to and from process" to a class there is a bug in the process.vi

The exit command that is sent to the process when stop process.vi is called will not properly exit the process if the front panel is open. As FP.Close invoke node is called in this case. This will abort the VI at UI: Cleanup state and not execute the Core: Cleanup state. Se attached image over the code in the process.vi that will fail to execute correctly if the FP of the process.vi is open.

[Bas-vE]

I cant seem to reproduce this issue. When I start a class with a process and show the process.vi, when I then call the destroy.vi which calls the StopProcess.vi (which calls the cmd: exit in the process) it will send the "finished" message back to the StopProcess.vi, this way I know for sure the Core: cleanup is called.

Can you show me the procedure you do while this is happening?

[jonasmaki]

Thanks for the quick response. I too can't replicate this issue in 22.3 and 23.3 anymore. But I know it has happened a few times for me in the past where the fp.close will abort the running process.vi and skip the last state. I usually have had one or more active objects composit aggregated from the first active object and I destroy them in the Core: Cleanup state. They have kept on running after the main obj is force stopped with the FP.close. I could see how the subobjects would still be locked in the project although the main obj is stopped.

But for now we can close this bug as not reproducable, I will make sure to post again if I find a place where it doesn't shutdown correctly.

I do believe good practise could be to core: cleanup before UI: cleanup to make sure that the FP is closed as a last step rather than continue working behind the scenes if the fp was opened when stopped.

[Bas-vE]

I know what you mean, and I also know why this problem may occur. Are these composite aggregated objects created in the process.vi? or in the create of the the class?

The reason I'm asking you this, is that LabVIEW has a tendency to clean up references when the last vi that uses that reference is no longer in memory. This is a known thing and should always be considered while creating by reference objects. We will investigate to confirm this suspicion.

[jonasmaki]

I've created them in the process.vi more precisely they where created in the Core: Initialize state and destroyed in the Core: Cleanup.

Yes I know about this issue and maybe the Core: Cleanup might have been executed but as the process.vi fp.close happened LV garbage collection might have gone and killed the reference to the composite aggregated object before destroy of that class is called..

[MikaelHolmstrom]

In the past (before classes), I always solved this by the Process VI started by opening a reference to itself. Then even if the FP is closed LV won't stop the VI since there is an open reference to thew VI, and the last thing I did was to close the VI's reference. That will also stop the VI, so any code after that Close Ref, will not be executed.
So we could of course add something like that.

[jonasmaki]

Interesting Mikael! Just as a curios thought. Wouldn't calling the fp.close as a last action in the exit macro be a solution that would deal with this as well. This would require less code outside the process.vi. The only way the cleanup of UI would require to be run before the core: cleanup is if any of the objects that are destroyed in the core: cleanup is needed for the UI cleanup. I've never made any dependency like that to my active process UI so it wouldn't be an issue to me.

[Bas-vE]

We are going to investigate if this only happens when calling the destroy, because this also destroys the process repository, which would cleanup all the references or if it also happens if you call the the closing of the process separately. if the latter happens, then this is a bug.

I don't recommend creating "by reference" classes in the core: init and cleaning them up in the Core: Cleanup because these cases are there to init and cleanup the core of the process. so a better way of doing this is make separate cases for initialising and cleaning up your classes. this way you also have more control over the order of creation and the order of cleanup. But we should still find a solution for this because, for users that are not that experienced, this could be a very time consuming bug.

[jonasmaki]

I agree with your point on the separation of cases and cleanness of the code.