FP.Close invoke node doesn't close Front Panel in application

[Leukocyte]

Hello there,

so this is the method I've found to close the front panel after the application is finished. Works fine when I try it in development mode and set the case structure to development mode, but when setting the case structure to run time system and building the application, the front panel stays open. I've been using this as a starting point. I can only assume that the error comes from the file path. And no, I won't use "Quit Labview", as it's annoying to having to restart Labview and I'm worried that it will shut down other applications that are supposed to run at the same time.

Have a nice day.

[dan_u]

I think your assumption is correct regarding the path. You can't build VI paths the same way for compiled applications as you do in development mode. In a compiled application the VI is inside the exe. Maybe it's better to use "Current VI's Path" (instead of "Application Directory") and strip the VI name, then build the path with the desired VI.

[GerdW · Accepted solution]

Hi Leukocyte,

I can only assume that the error comes from the file path

Then why don't you debug this? Use a dialog to have an indication of the path you build there!

And no, I won't use "Quit Labview", as it's annoying to having to restart Labview and I'm worried that it will shut down other applications that are supposed to run at the same time.

When you run your "application" I guess you talk about executables created by the AppBuilder.

Such "apps" run in their own process/instance and using Quit function will only terminate that process/instance…

One possible solution:

Instead of using a path input "VI name" you could use a VI reference input. Wire the VI reference into your subVI!

Another solution:

Use a string input for "VI Name" and wire that string directly to OpenVIReference. It will pick the correct VI as long as there is a VI of that name in memory…

@Dan:

The OP wants to close the FP of a different VI (the shown VI is used as a subVI), so using "Current VI path" is of no use here…

[dan_u]

---

@GerdW wrote:

@Dan:

The OP wants to close the FP of a different VI (the shown VI is used as a subVI), so using "Current VI path" is of no use here…

---

And why would that be? I assume the VI which needs to be closed is in the same application. When using current VIs path and strip the VI path you have the exe path. Then you can append another VI name (of course this depends on the directory structure).

[GerdW]

Hi Dan,

so you want to replace the correct "App path" by a Rube-Goldberg "Current VI path" that you have to strip later on?

[dan_u]

The application directory does not contain the exe name. If you have two VIs in the same directory getting the path of VI 1, stripping it and building the path with the name of VI 2 is a simple method.

[GerdW]

Hi dan,

If you have two VIs in the same directory

- The CloseApp-VI as shown in the image above should be placed in the user.lib.

- The mainVI that is getting closed should be placed in a project folder somewhere else.

- Since LV2009 the folder structure is maintained inside the execuatable so both VIs will not share the same folder.

Conclusion: You still have to know the folder of your mainVI and it is still easier to attach folder/main.vi to the AppPath…

[Leukocyte]

I guess I didn't make myself very clear, sorry for that. But GerdW got me right, this is actually a subVI used in the main VI that's the basis of the .exe application I'm building (first .exe ever, so bear with me). I've been starting this with the exemple I've linked to, so to use the Application Directory and append the name of the main VI seemed quite logical. Inserting an indicator into this (tried before) only showed me that in the built application, the Application Directory linked indeed to the directory of the .exe. But obviously, there was no VI of that name in there, so that's what told me that I needed to go about this differently.

Using the Quit Labview function made my Labview project (that was still open from building the .exe) (and indeed every other Labview related window) shut down, so  I assumed that would be the case for every Labview application. Besides, while I'm still developing, I'll still try out different things in development mode, so I'll have still programs open and I don't want to restart them every time.

Using a reference to the VI is indeed doing what I want it to do, meaning only close the .exe application when it's finished running. This way is indeed much easier (and more logical) to use than the example I've started with. Like always, I guess I should have known... Also, the reference was the first method I've tried cause it seemed the easiest way of doing it. Haven't given the others a shot yet.

Thanks for your kind and quick answers!

[GerdW]

Hi Leukocyte,

Using the Quit Labview function made my Labview project … shut down

Simple solution:

IF App.Kind = Runtime THEN
  QUIT
ELSE
  STOP
ENDIF

You don't need to quit in every case, you can just stop if needed! 🙂

Inserting an indicator into this (tried before) only showed me that in the built application, the Application Directory linked indeed to the directory of the .exe. But obviously, there was no VI of that name in there,

Simple solution: Did you also add the executable itself as additional folder to your VI path?

When you have a "Main VI" in your executable you will get a VI path like "App folder" \ "Executable name" \ "Main VI"…

[Leukocyte]

Well, if the App.Kind = Runtime then Quit Labview is just what made my Labview project shutdown. I've build the executable with this logic (at least what it seemed like to me).

So the .exe file works just like another folder level in this case? This is good to know. Anyways, this is just for my personal information, the reference method works perfectly fine, thanks again 🙂