Block-Diagram-Only VIs (VIs without a Front Panel)

[Petru_Tarabuta]

I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.

BD-Only VIs would be beneficial because:

• They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
• They would reduce the developer workload, thus making developers faster.
• They would reduce the surface-area of the codebase.
• They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.

BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?

Notes

• I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
• The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagram idea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
• Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
• I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
• It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.

Thanks!

[GregSands]

I had a similar idea on here many years ago: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/The-Block-Diagram-should-be-the-central-VI-component-...

It was closed as completed, given similar functionality was present in NXG. Given that NXG is now dead, perhaps this idea is not so complete after all.

[fefepeto_kb]

I agree that it's not trivial. As LabVIEW user, I have done quite a few scripting tools. Based on that here are my thoughts:

• "They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI." FPs act as headers in C and C++, and function definitions in modern languages, so it's not entirely true.
• The terminals on block diagram have way less properties than Controls on the front panel, like display option for numerics, the ability to define enum values, etc.
• Having terminals only would need a new method to implement default values for optional "parameters".
• Harder debugging since unable to see the high level inputs and outputs, forcing the use of debugging on VIs that are intended to be inlined and the use of probes.
• The non-GUI VIs front panels could be scripted to be cleaned up. Indeed I would advise to create a script that goes trough groups of VIs and does a generic cleanup like the Nattyfier: clean up front panel, move error Wires to the back, disable auto-grow on structures, etc. all with options that can be saved in an INI. Maybe multiple INIs for multiple types of VIs, i.e: GUI VI don't have the FP touched. Reference Quick Drop Keyboard Shortcut - Nattify VI - NI Community
• "Do most class accessor VIs really need a GUI (the Front Panel)?", YES, but the front panel of override VI could just be a reference to the parent class's VI's front panel. The reason for "yes" is the multitude of VIs with the same name for different classes, like Init, Construct, Destroy, Close. Doing active work on large number of classes is evident by the class name, but a new developer coming in the picture or taking a look a few months later can really help to understand what data is coming in to these VIs.

[Petru_Tarabuta]

Hi Greg,
Sorry that I hadn't come across your idea before, but I support it.

fefepeto_kb:

• "They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI." I stand by this statement. Creating headers in C/C++ does not involve touching or working with a GUI. It is still done entirely from the keyboard, which is faster. It does not involve aligning controls and indicators and/or distributing them vertically or horizontally.
• "The terminals on block diagram have way less properties than Controls on the front panel, like display option for numerics, the ability to define enum values, etc." I agree. This is part of the implementation challenge.
• "Having terminals only would need a new method to implement default values for optional "parameters"." I agree. And, in addition to definding default values, it would be nice to be able to define the input value of controls (something equivalent to typing a value in a FP control). This is part of the implementation challenge.
• "Harder debugging since unable to see the high level inputs and outputs, forcing the use of debugging on VIs that are intended to be inlined and the use of probes." I agree that not having a FP to see the values of controls and indicators would make debugging slightly harder. It is for the programmer to decide on a VI-by-VI basis whether they would benefit from using a BD-Only VI or from using a traditional VI. I would be happy to use BD-Only VIs and use probes if/when I need to debug them.
• I am aware of Nattyfier and other tools that can help clean-up the FP. I have written similar small tools myself for my own use. These tools are helpful and reduce the overhead associated with tidying up the FP. But it would be best to not need to use any tool at all - the overhead would then be 0.
• "Do most class accessor VIs really need a GUI (the Front Panel)?" I still believe that the answer is no. While it might be helpful for a new developer to see the Front Panels, this is not a strong enough reason to force all such VIs to have a Front Panel. Again, it would be a case of each team adopting the style that suits them best. If the team believes that it would be best for them to use traditional VIs to help new developers, that's fine. But another team might still prefer BD-only VIs.

[Neil.Pate]

Well, taking this one step further, I would suggest that the terminals on the block diagram actually display the input/output values, just like a constant.

[leahmedwards]

Interesting idea. Reminds me of the way VI snippets works. 

I think personally I'd prefer to be able to temporarily set the IDE to not open Front Panels if I'm just statically reading code, as all of those extra subVI front panels make navigation more difficult. Either that or have a 'Hide Front Panel by default when opened in IDE' option as a VI property.

However I'd definitely want the option to bring Front Panels back again when I pressed Ctrl+E! I tend to use them to test my code in even the simplest VIs. 

[Taggart]

How do I vote twice for this?

[fefepeto_kb]

To leahmedwards, that idea is discussed here: Make the default behavior of opening a VI open ONLY the block diagram - NI Community.

This just makes cross referencing since this idea is mentioned there :D.