Open jimkring opened 10 months ago
I like this and it can solve the questions around #137
I feel like it would be best with 3 options:
The last option would be default so that coming to Linux would work in a sensible way by default.
The problem would be that it is a breaking change for:
In both cases, I suspect they have implemented this function themselves anyway, but the timing may be different and cause problems.
Hi James. I'm not sure if I quite understand the different options you mentioned.
My thinking is that the current behavior of G-CLI is that it is up to the LabVIEW code to decide to exit (call the LabVIEW quit/exit function).
I would be very happy with a new --exit
flag that defaults to False and is handled by LabVIEW inside the g-cli close session VI (behind the scenes where I can't see it).
Since the default setting/behavior (I've suggested) is False (Meaning: do not exit LabVIEW) then adding this feature would not change the default behavior for existing users in any way (I think).
I've probably used the wrong terms actually. So don't exit or always exit is exactly what you have described.
What I'm trying to capture with the other option is the times that you probably do want to exit based on the launch context. This has 3 use cases:
By adding the 3rd option I basically want the same command to exit in these 3 instances but not in other cases.
However an alternative approach is maybe that distinction should be set in the LabVIEW code by the tool developer who may be better placed to decide on that differentiation. What do you think?
One idea (that might be nice in addition to the
--kill
option) would be to add a new--exit
flag (to "Exit LabVIEW on Completion") that is received by theStart CLI Interface.vi
, passed along the session wire, and then handled in theExit with Error Code.vi
by invoking LabVIEW's "Exit" function:I've been doing this as a user-defined, additional argument, and it would be great it it were built in.
Originally posted by @jimkring in https://github.com/JamesMc86/G-CLI/issues/137#issuecomment-1692142276