[Best Practices] Closing vs. Hiding front panel

[Gregory]

Hi there, I just wanted to point out and gain some more clarity on closing vs. hiding a front panel. For those who don't know, you can hide a front panel using the method FP.Open -> Hidden. You can close a front panel using the method FP.Close. To the user, both of these look the exact same, but there are certain cases where the behavior is different.

VI Running: VI stays running when hidden. VI stays running when closed if other VIs are open, but stops if no other VIs open.

Subpanels: A closed front panel can be inserted into a sub-panel, a hidden front panel cannot.

For a while I would use only the FP.Open with Standard or Hidden as the argument to show and hide a front panel, which avoids the case where all front panels might be closed accidentally, stopping the code when you don't want it to. Then, when I stop the code I check if the front panel is hidden and if so I close it so we aren't left with a hidden panel. Recently, I wanted to use sub-panels for a pop-in and pop-out type of UI, which requires actually closing the front panel so I can insert it into the sub-panel.

Attached is a project showing some of the behavior I mentioned. If you run Main.vi you can open, hide, and close the SubVI, while keeping both VIs running. If you press "Close Both FP", both front panels are closed and the code stops executing, even though the loops are not stopped. You can re-open Main.vi through the project explorer to see that it isn't running.

So this is kind of an open ended question. I just wanted to share what I have learned so far, and see how others prefer to show or hide front panels from the user, and any other use cases you've found where hiding and closing a front panel are different.

[aputman]

I use the JKI state machine frequently and it maintains an open reference to the main VI.  That way the VI keeps running after the front panel is closed and references can be cleaned up.  The last thing it does before exiting is to close the main VI reference.  Pretty slick, IMHO. 

[Gregory]

Hi aputman,

I have edited the Main.vi to do as you said, but it still appears that closing all front panels will stop the code execution. Revised project attached.

[aputman]

I take that back.  In looking at this closer, when running in the IDE, the UI: Front Panel State >> Close step is skipped and the reference is deleted.  This prevents the developer from having to reopen the VI every time the app is executed and closed. 

But when this is compiled into an EXE, the UI: Front Panel State step is not skipped and FP.Close is called and the EXE is closed.  The subsequent states (Data:Cleanup and Exit) are never executed in that case.

[aputman]

---

gregoryj wrote:
VI stays running when closed if other VIs are open, but stops if no other VIs open.

---

This isn't entirely accurate.  If the other VIs that are open have a reference to the subVI, the subVI will continue to run, even with it's front panel closed.  In your case, you have a static VI reference that keeps the subVI loaded in memory (until main is closed). 

However, if you open your subVI with the Open VI Reference, and then add another button to delete the reference, the subVI will run continuously (same as before) until you delete the reference.  Then there is no other VI holding that reference open and when FP.Close is called, it's removed from memory. 

[Gregory]

Hi aputman,

I have just verified this behavior you mention, thank you for pointing it out!

[JÞB]

One of the times I used that property  FP.Open -> Hidden. was when calling a bunch of "Resource Modules" (AKA FGVs) to "Init" a group on VISA and DAQmx Resources from TestStand (Yup, in the Pre-UUT-Loop) 

Since the TS Model unloaded the Pre-UUT loop sequence modules from memory, all the FGVs unloaded and the "Resources" (VISA and DAQmx on the FBNs or SRs) died a painful death became invalid and tossed errors about dead resource descriptors. FP.Open Hidden. keeps an LV Object's dataspace in memory.

It was a "Hack"