Add a property to guarantee that the front panel of a VI will stay in an executable

[tst]

By default, when you build an application, the front panels of all VIs are removed.

Of course, this would make applications completely unusable, so there are certain changes which cause LV to keep the front panel in, such as setting the front panel to open when the VI is called. This gives LV a clear indication you want the front panel and these changes are generally enough for most of the VIs which people use.

There are, however, times when you want a VI to keep the panel, but it's a VI which usually (or sometimes even never) won't be displayed. Today there are several ways to handle this case.

The official way is too flimsy:

It's limited to specific build specs and it's too easy to break (e.g. remove the VI from the project and add it back).

The automatic way relies on additional changes you're likely to make if you intend to show the VI, but is also too easy to break:

Someone could just unset the property and then it's gone.

What I usually today is something like this:

The static property node ensures the FP will remain and the comment makes it less likely that someone will remove it.

What I want to see, however, is something more explicit, possibly in the shape of a new VI property:

[AristosQueue (NI)]

My objection isn't that the checkbox is mutually exclusive with the automatic detection; my objection is with (yet another) an off-diagram checkbox that can be forgotten/overlooked/misunderstood. Sometimes a feature has no good implementation mechanism other than such checkboxes, but in this case, I think there's a better way.

[wiebe@CARYA]

> but in this case, I think there's a better way.

What is the better way? Something existing or something new?

A reference to a FP object will be easily forgotten/overlooked/misunderstood, and also hard to search for and easily removed by mistake (as consequences of G/O/M).

[AristosQueue (NI)]

Weibe: The entire write up I posted previously covers why I believe the existing approach of detecting from the diagram whether to include the panel or not is the better way.

[wiebe@CARYA]

That is all based on the idea that this option is\should be linked to the usage on the diagram.

When you want to keep the FP because you're dynamically calling the VI, setting it's control values by name, this behavior is independent of the diagram of the VI.

In this situation. a reference to a control can also be forgotten to be removed when this behavior changes... So if a reference is the solution doesn't that have the same downside as the VI option? On top of that, the reference will (a matter of time) be removed because it's purpose was forgotten. (A comment might fix that, but it wouldn't be self-explanatory).

I'd also like to be able to search for explicit 'keep FP open', and that would be possible with an option.

Perhaps a special node (like the 'request deallocation' (that we shouldn't need to use )) would work? That is on the diagram, gives a clear signal, is explicit and is traceable.

[AristosQueue (NI)]

> That is all based on the idea that this option is\should be linked to the usage on the diagram.

Yes. That's my entire point.

> Perhaps a special node

That's a better mechanism in my book than VI Properties.

[wiebe@CARYA]

>> That is all based on the idea that this option is\should be linked to the usage on the diagram.

>Yes. That's my entire point.

But that is not my situation. With dynamic calling, and where Call By Reference is not practical, I need the FP although the FP is irrelevant to what's on the diagram.

>> Perhaps a special node

>That's a better mechanism in my book than VI Properties.

Sounds like a plan .

[IlluminatedG]

This was just raised in an issue opened on one of my UI libraries I have on VIPM. It dynamically gets references to UI VIs in child classes (A hierarchical OOP UI library) and due to removing the need for a bunch of the boilerplate and control typically associated with , it's very easy to have a UI panel that's meant to be embedded in a subpanel or opened as a standalone window (or inserted into a panel and then promoted to a standalone window) and not use any property nodes and the framework handles making the panel visible so that option doesn't get set in VI properties.

The entire point of these override VIs is to be a visible UI panel. These VIs will ALWAYS want to have their front panel retained regardless of how simple they are. There's no way to enforce the FP to remain and half the point of the framework is to make  panel implementation simpler. It's a VI that's created from New VI for Override so I can't enforce any specific contents and it's not feasible to force users of the framework to use specific features to trick LV into keeping the panel for all use-cases.

I hope someone besides Stephen can speak to this. I also don't think the argument of "what if someone turned this option on and forgot to turn it off?" is valid because I don't see when I'd make a VI purposefully be a UI and then not want it to be. LabVIEW conflates UIs with method I/O and has to make guesses which it will never get right 100% of the time; it's guessing based on some heuristics a couple of people can think of ahead of time. I think a checkbox to force keeping the FP is the best option and that it should follow along to overrides in children as well for DD VIs.

[wiebe@CARYA]

This is not limited to UIs.

VIs that are dynamically called through Run VI do need the FP to set control values, but these aren't UIs. Call By Reference and friends can use the CP, but you don't always have or want to use CP info.

There's already a property for this (, but it's in the exe build specification, while it should be VI scoped.

[IlluminatedG]

For sure. I think the point is that LV will never be capable of being all-knowing so there should be an explicit option available for people that want to tap LabVIEW on the shoulder and say "Hey, make sure you keep this".

If I set it and then forget to unset it (for reasons I can't foresee right now) then that's on me. Just because a situation can be imagined where someone forgets to change a setting back isn't justification for that setting to not exist. By that logic none of app builder or most of LabVIEW should exist since I can do stuff like put a non-existent file as the input to an open file node and have combinations of builds and settings that produce executables that can't load and run. How do I know that someone didn't typo a number in a formula on a block diagram? How do you protect against that? That's what training, documentation, and software testing is for.

[tst]

Derrick, you might want to actually vote for the idea. I doubt that would move the needle, but at least it would prevent Darren from closing it in 2041...