01-05-2023 07:27 PM
I have a VI that works fine when run as a VI, but when I use application builder to make it into an .exe, the application can sometimes just quit with no error. I am using LabVIEW 2019.
Solved! Go to Solution.
01-05-2023 08:11 PM
Well, you can look at the code and figure it out, right? Or do you want us to "guess" what you've done and explain the behavior? Note that for us to figure it out, you need to include the entire LabVIEW Project as an attachment so we can "try it for ourselves" and maybe explain what is going on.
An alternate thing you could try is to find a local LabVIEW expert and go over your code with her (or him). You are (almost certainly) doing something wrong -- either you figure it out for yourself, or you let some else (one of the Forum participants, perhaps) see exactly what you are trying to do, and either (a) see the same thing you do, or (b) see what needs to be done to make it work as you'd expect.
If you decide to get help here, do the following (please) (note -- this assumes you have your LabVIEW "project" organized as a "LabVIEW Project", a series of VIs and an associated LabVIEW Project declaration (with extension .lvprog) that includes, among other things, the Build Specification):
Bob Schor
01-05-2023 09:35 PM - edited 01-05-2023 09:54 PM
As what I do is proprietary, I am not going to show my code to the world.
I was more interested in if anyone else has enough insight into the idiosyncrasies of the application builder (AB) of LabVIEW 2019.
For instance, does the AB have some unpredictability when using modal windows, floating windows, or using invoke node to open and close front panels. My high-level app is floating, and my three sub apps are also floating while anything they call is modal, and only one modal window is ever used at a time, such as a password setting VI that has to be on top when it is called, and then exits normally.
When the password entry VI exits and the calling VI is supposed to open its front panel back up, the whole application just exits without any errors even though every VI has a simple error handler at the close of each one. I should also note the password VI is a password protected VI. I am wondering if that is causing some issues when it gets called by the prior password set VI.
As I mentioned, when I run this project within LabVIEW, there are no problems and no errors. When I build the application, I get this inexplicable 'quirkiness' when calling subVIs. Does anyone have any insights or BKMs for the Application Builder where it can be finicky with invoke nodes? I added the build specs.
01-06-2023 12:36 AM
From what you described I can't see any problems. Make sure that error handler pops up an error window if there actually is an error, I presume that closing the VI before EH execution shows nothing. If there is no problem with error handling (maybe you've missed an important error wire), then the code works as expected. You'll have to isolate the problem and find the minimal "not working" example, it is tedious but we all went through it. The good thing is that at some point of removing stuff, you'll even be able to show us your code!
01-06-2023 03:30 AM
There is a "feature" of the LabVIEW executable that will cause it to close and be removed from memory when the last front panel is closed. Make sure the main front panel remains open while the password VI is executed!
01-06-2023 01:12 PM - edited 01-06-2023 01:29 PM
Hello Lucian,
You make an excellent point. For the purpose of elegance, I like to close the front panel of a calling VI so that the called VI will be the only one present, otherwise I end up with a bunch of stacked front panels and it gets cluttered. I know that property nodes and invoke nodes do not work if there is an error entering the node, so I accommodate that by adding an unbound invoke node after the sub VI call. (see pictures). If there is an instance where I closed a front panel when I call a sub VI, then after the called VI closes naturally and the calling VIs front panel does not open, then there would be no active front panels and the program would just 'exit' without error. Is there a better way of closing front panels temporarily when a subVI is called and reopening them when the subVI exits?
James
01-06-2023 01:38 PM
Set their state to hidden, not standard.
01-06-2023 01:43 PM
@DerrickB wrote:
Set their state to hidden, not standard.
At that point I don't want the calling VI to be hidden after the subVI closes. However, maybe I could just set the VI to hidden before the subVI call (as opposed to 'closing' the front panel), then I can just unhide it upon subVI exit. I'll try that.
01-06-2023 01:54 PM
I didn't say when to use it, just letting you know that Hidden is the state you're looking for to hide them without closing them. This means changing/adding code since you'd be changing how the code handles visibility state.
01-06-2023 02:01 PM
@DerrickB wrote:
I didn't say when to use it, just letting you know that Hidden is the state you're looking for to hide them without closing them. This means changing/adding code since you'd be changing how the code handles visibility state.
I understand. It turns out setting the VI to hidden isn't available when the VI is active, but I can set Front Panel transperency to 100 when I call the subVI, and then set the calling VI transparency back to 0 after the subVI exists. I have to make sure the Window Appearance setting in the main VI for "Run VI transparently" is checked. This works and is a lot safer.