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:

[altenbach]

> 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.

Under what conditions would you want to keep the FP, even if it is never shown?

[tst]

Some examples:

1. Uusing a subVI to get the size of text (although that can also be done using the Get Text Rect VI, which is probably also faster).
2. Creating printed reports with a custom design, which is much easier to do with a VI than with other means.
3. A VI which is only used for debugging, so under normal circumstances you would never see it.

[Jarrod_S.]

@Altenbach - You need to retain the front panel to be able to use the Set Control Value method on a VI, which is commonly done when running a VI dynamically. If the front panel is removed, this method fails silently. This induces bugs that are very difficult to debug.

[AristosQueue (NI)]

Jarrod S: Instead of using Ctrl Val.Set, use the Asynchronous Call By Reference nodes new in LV 2011. Works much much much better in these cases (on the same machine, avoids the translation to variant entirely, your diagrams are cleaner, and you catch terminal problems at compile time instead of at runtime).

Tst: Of your use cases, #1 is going to involve some property nodes, so the panel should already be in memory (and, your're right, Get Text Rect.vi is faster). I've never done #2, but I'm surprised it doesn't involve some property nodes. Can you talk about that one more? Which leaves #3. Keeping the panel creates a performance impact, so you would never want to keep the panel in your actual release build. To me, that implies that when you build your app for debugging, you're doing a separate build spec anyway in order to tell LV to keep this particular panel around. Under what conditions would you build the panel into your final release app if it isn't part of your final UI?

[tst]

AQ, I didn't include any specific examples in the idea on purpose, because I didn't want this to become an endless "How do we automatically take care of this case?" race. Note that I only gave the examples in response to Altenbach's very specific question and the only reason I gave those examples was because they were fresh in my mind. Others may have completely different needs. I understand that NI tried to handle this automatically, and for the most part, it works perfectly, but I'm guessing there will always be cases which can't be handled automatically. Frankly, the workaround I use today is reasonable, but I would like something more explicit.

As for the specific examples I gave, you're right that #2 usually involves property nodes or static references, but not always (since I ran into this issue), and for #3 I am definitely talking about keeping the panel in the release build. This is useful in cases where you have problems in (usually complex) subVIs and you want an easy way to troubleshoot. In those cases, filling the FP with relevant indicators and simply toggling a debug flag which opens the FP when the VI runs can make troubleshooting a lot easier than digging through log files and the code for it is also generally simpler than logging everything. But again, those were specific examples, not reasons for the feature.

[Todd_Lesher]

4.  A VI has some subpanels. Each of the subpanel refs get passed to dynamically dispatched VIs.

[wiebe@CARYA]

An event structure in a disabled case used to do the trick.

Now in 2018, even FPs of VIs with an event structure and property nodes get removed.

We're running out of options here...

BTW Asynchronous Call By Reference would require all CPs of my VIs to be the same, or a ACBR for each CP type... Both are impractical in some situations.

[AristosQueue (NI)]

Any static use of the panel will keep the panel. Disabled code is not a use of the panel. It is sufficient to create a reference to any control on the panel (right click on control and select Create >> Reference). You don't have to wire the reference to anything. Just don't put it in a diagram disable structure.

Note that I am posting this in response to Weibe's comment. This should not be read as a reason not to implement this idea as proposed. I'll put some more comments about this below.

[AristosQueue (NI)]

So, this idea raised its head again. I have an argument against this feature. Anything that is a VI Property is a fixed aspect of the VI. It doesn't shift based on usage of the diagram. In general, the more we can get LV to decide correct behavior based on what's on the diagram, the more often you get correct results. You might have a VI that needs to keep its panel, so you turn on this option. Then you change how you're using this VI, but you forget to turn off this option. The VI continues to retain its panel. If LV could correctly divine how you're using the VI and retain the panel or not, you wouldn't have to remember to set/clear this option, and this option wouldn't be "one more setting for users to understand and have to check when things aren't working right." 

Tst's response to me was, "I didn't want this to become an endless "How do we automatically take care of this case?" race." But that's exactly what I think is the ideal scenario for most options like this. If we can automatically take care of it then you can have code in a conditional disable structure that causes the panel to be retained sometimes (e.g. only when debugging) and be dropped other times.

The idea remains open, but I'm personally skeptical that it is a good idea compared to LV automatic evaluation. Yes, there was a bug in that evaluation that is fixed in LV 2018, a bug that some people were taking advantage of. That's a bad mistake on our part, but I don't think it means that the automatic isn't generally the better path.

[tst]

---

I'm personally skeptical that it is a good idea compared to LV automatic evaluation

---

I don't think it's a zero sum game. There's no reason not to have the automatic evaluation. Like I said, it works well for the vast majority of the cases. I just need something for the rare cases where the automation doesn't work and while my current solution is reasonable, the explicitness would have been appreciated.

Today, I use the property node method relatively rarely, and even so probably more than I strictly need to. I would be perfectly fine with a case where I marked a VI as needing to keep its FP and it would continue doing so even if the reason for it stopped being relevant. Since this is meant for handling the corner cases, I'm OK with it erring on the side of making the EXE bigger.

That said, that's my personal opinion. I can't speak for other users who might have difficulties with such a setting.