Enable 'Remove front panel' Option when building packed library

[jiaweipray]

Hi:

       The size of NI Package Library is too large for it includes so many graphic programming information such as front panel.In our view,it is not necessary when the vi is used as function,but not UI.But the 'Remove front panel' Option in the Soure File Settings Config Dialog is disable for user to select.In our point,LabVIEW should allow users to decide each VI wheather to include front panel or not when building a package Library.

Project->build->Packed Library Properties:

[qiubin2006]

It‘s a good idea and very important to improve Packed Library performance！It's useful for application to load Packed Library with smaller size faster！

[tst]

I don't know about PPLs specifically, but generally, LV keeps the FP of a VI when it decides that it needs it. This happens, for instance, if you configure the FP to open when run, or when you change some of its window settings or when you use a property node for one of the controls on the FP. I'm guessing that's what happening here. If you remove the relevant reason, I'm assuming LV will remove the FP on its own.

Also, you say that the FP impacts the size of the code. While that's true (and it's probably one of the main reasons LV removes the FP by default), it doesn't mean that this takes up a lot of space. You can see how much space the FP data of a VI takes if you look at the properties for it right after loading it. Generally, unless you have images, large default values or quite complicated FPs, I don't think that it takes up much space, although I'll admit to never looking closely at the number. I'm guessing that if you have performance issues, your problem is probably elsewhere (not so wild guess - are you using Value properties?).

[SteenSchmidt]

The FP can easily take 1/3 of the overall space of a VI, and it takes time to load it, so it makes sense to remove it if possible. Also I agree with the OP that it should be possible to override the default selection - not to remove the FP if LabVIEW has decided you need it (which LabVIEW isn't too good at guessing anyway), but the other way around; that you have the possibility to include it even when LabVIEW can't determine you need it (you might know otherwise).

/Steen

[GregSands]

Even better, don't create a Front Panel in the first place!  Only create one if you need it. 

[AristosQueue (NI)]

Been having discussions with others on the LV team about this idea... I would have just assumed that we were stripping the panels. I got a number of good reasons why we don't do that, but I believe I have a workaround.

There were two good arguments I heard against removing the panels:

1) PPLs are dropped as subVIs, and we want their experience to be just like using the subVI as much as possible. Part of that experience is being able to open the panel -- a major advantage of LabVIEW is that any 3rd party API can be experimented with by putting values into the front panel and running it, something that is often critical for covering for weak documentation (weak documentation is common in all languages, LV just happens to have this compensation mechanism).

2) We do not know how the functions in the PPL will be invoked. If they are going to be invoked using VI Server and an Asynch Call By Reference node or the Run method, that means they are running as top-level VIs. LabVIEW cannot (for reasons embedded in the code 20+ years ago so deep that the assumption is not rationally changeable) execute a top-level VI without a front panel. To maintain the ability of a PPL function to be invoked either as a subVI or as a top-level VI, we need to retain the panels.

These aren't bad arguments, but I believe LabVIEW can simply generate a front panel on the fly -- as if it were newly loaded from disk -- to match the connector pane, even in the runtime engine, doing such generation only if the panel is actually needed (just like we only load the panel if we actually need it). Making changes to the FP may cause a VI to need to recompile, but in this case, we would be generating the FP to match what was already compiled. Yes, we would have default controls/indicators for all the types, not the fancy XControls or customized displays, but it would suffice for the editor experience.

I'm recording this here in case work does ever proceed on this idea. And I'll kudos the idea.