In an executable environment is there a property that tells me if a VIs front panel is in memory?

[WNM]

From the viewpoint of another VI within an executable environment (using VI references), can one VI tell if another VI's front panel is available in memory or if it has been stripped out by the application builder? 

As an example (assume execution in a runtime environment):

A (top VI) calls B which calls C which calls D.   Both A & C have front panels. Neither B nor D's front panel were included in the executable by the application builder.  SubVI D looks at its call chain and tries to determine which VIs above it have front panels (open or otherwise).  Is there a property or method that returns this information?

I checked the FP.State property, thinking that this might be a good use for the INVALID front panel state return option when "B" does not have one available, but even in an executable environment, when B's FP state is checked, it just shows up as CLOSED.

I have found that if I check/read a property like FP.CustomTitle,  a Boolean property which will cause a front panel to be loaded into memory if referenced, if the property returns an error, then the referenced VI does not have an accessible front panel.  While this "try and and see if it returns an error" may be the only/best way to test for this, it stuck me as a bit kludgy so I thought I'd ask if there was a better way

Thank you.

[JimB.]

What you are doing works, but if you want something slightly more elegant you can check whether the front panel refnum is valid by comparing it to a default panel ref constant.

See the attached project zip.

A just has one button that calls B.

B just launches C as a modal dialog with one button and a table showing the call chain.

C calls D to populate the call chain table and waits for the button to be pushed.

In the development environment, you should see:

If you execute the build spec and run the exe, you should see:

D.vi.

 

[WNM]

Hi JimB,

Thank you for the reply.  While I like your proposal and I agree that your solution is more elegant, it is also a tad more complex and will likely take more CPU cycles than what I am doing now.

I can go on to use the FP.CustomTitle return value if the FP is accessible whereas I don't particularly have a use for the panel reference and it needs to be closed once acquired. 

Here is a screenshot of what's working for me now (the various error cases include custom error handling). Here I just need to first try a FP access using a property (like CustomTitle) that will test the existence of the FP and if the FP is available, go on to get more properties of the FP. If the FP does not exist then the error is discarded, the VI reference is closed and the data cluster updated to indicate that the VI does not have a FP.

Thank you again!

[wiebe@CARYA]

---

@WNM wrote:

From the viewpoint of another VI within an executable environment (using VI references), can one VI tell if another VI's front panel is available in memory or if it has been stripped out by the application builder? 

---

Try to get a reference to the Front Panel.

If it gives an error, there's no front panel.

Not tested, but that's what I'd try.

Do wire the output reference of the property (to a sequence structure or whatever). If you don't the property is probably considered dead code, and not executed.