VIs without Front Panels - or with several!

[GregSands]

This is a shameless plug for a new idea I've submitted to the Idea Exchange suggesting that by default, a VI should not have (or need) a Front Panel. Connections to the con-pane are defined from the Block Diagram - after all that's where the data is used, and the subVI interface to that data should be specified. One (or more) Front Panels can then be added which provide a user interface to the BD data (controls/indicators). Perhaps one is the standard run-time view, and another is a debugging view (like an enhanced Probe window). Or for many subVIs, there may be no FP at all.

Kudos (or critique) welcome!!

[asbo]

I think this response isn't as thorough as the idea probably deserves, but in short it's an interesting perspective but seems like a pretty radical change to the LV paradigm. The FP and BD are pretty comfortably categorized functionally and I don't often find myself disagreeing with the delegation of functionality. The fact that it would be such a tremendous change to business as usual doesn't bode well for it being implemented.

[Grampa_of_Oliva_n_Eden]

This is a shameless plug for a new idea I've submitted to the Idea Exchange suggesting that by default, a VI should not have (or need) a Front Panel. Connections to the con-pane are defined from the Block Diagram - after all that's where the data is used, and the subVI interface to that data should be specified. One (or more) Front Panels can then be added which provide a user interface to the BD data (controls/indicators). Perhaps one is the standard run-time view, and another is a debugging view (like an enhanced Probe window). Or for many subVIs, there may be no FP at all.

Kudos (or critique) welcome!!

What part of the FP do you not like?

Re-entrant sub-VI techincally can have multiple FP (one FP for each instance).

If the FP is never shown it can be stripped in the build.

So please forgive when I ask "what missing or what are you trying to achieve?

Curious,

Ben

[GregSands]

What part of the FP do you not like?

First up, it's not that I don't like Front Panels! Rather, the idea comes from the recognition that, as evidenced by a fair number of ideas in the Idea Exchange, FPs often add unnecessary work to developing VIs. I was trying to pull a number of different ideas together into a solution, sparked by reading this idea which suggests adding yet another layer to a VI - and questioning whether we can reduce complexity instead of increasing it.

There's been some discussion on how to limit the FP to show only what's needed for the user interface (e.g. here). Having unneeded (from the interface point-of-view) controls and indicators on the FP means we need to work around issues such as edit-vs-run-time displays, setting up tab orders, rescaling controls (but only some of them) as panels change size, disabled code, and so on. The basis of my suggestion is not that we shouldn't have FPs, but that FPs should only contain what is needed to be seen by the user.

Secondly, the data that needs to be seen during development or debugging is often very different again. When we use a Probe, we essentially create a virtual indicator. Take the Probe Window slightly further in its development, and we now have a second FP, which contains another set of controls/indicators for showing, or setting, the data during execution.

Also, for many VIs, the variables that are passed through the conpane interface are not required to be shown in the user-interface - Error clusters for example. It makes sense to be able to link the conpane directly to BD controls, and therefore there is no need for the controls/indicators to appear on the FP at all - many subVIs without user interaction wouldn't need an FP defined at all. To me, the conpane has a much stronger link to the BD than the FP, as it is there to provide the programming interface to the code. The downside would be that it is perhaps more difficult to find terminals on a crowded BD, but that could be enhanced (e.g. mouse-over the conpane, and everything fades except for terminals).

Perhaps there would even be the opportunity to see the FP as a virtual cluster.

seems like a pretty radical change to the LV paradigm.

The LV paradigm presumably arises from the concept of Virtual Instruments, where the controls/indicators are what you define your instrument by - and much early code was all contained within one VI! This idea suggests that LV has perhaps grown past that stage, with far more emphasis now on subVIs, classes, libraries, etc which are maybe more like patch panels or breadboards (still thinking as an engineer!) - things that are hidden from the end-user. I don't see it as such a radical change - more a response to the way that LabVIEW is being used anyway - to make that process easier and more transparent.

Edited September 13, 2011 by GregSands

[Daklu]

I absolutely agree with you Greg. The front panel is a throwback to the days of widget-based programming. In some ways LV reminds me of programming in VB6. Widgets are great for RAD--which certainly is part of Labview's core audience--but as many of us have experienced they become too restrictive when trying to do something outside of the predefined functionality they provide. On top of that, widgets tend to couple business code to the UI, which hurts in the long run.

I recall other discussions where AQ or another blue commented that they are working towards the point where a block diagram can be loaded without loading the front panel, but it's a slow and tedious process. Perhaps once they accomplish that we can toss the fp altogether.