Add Data layer for VIs in addition to Front Panel and Block Diagram, because not all data needs to go onto Front Panel (user interface).

[Yakov]

The problem:

We have a Front Panel and Block Diagram for each VI.

Front Panel as of now serves two purposes:

* User interface

* Data declaration/container

EVERY time I have a VI that has user interface, I have to hide data elements (controls/indicators) that do not belong on user interface outside the front panel boundaries.

EVERY time I need to add/edit any data element I have to move the front panel to get to my hidden data. (Then you know what happens, right? You build the application, run it to find out that you forgot to shift the user interface back, and your application shows data guts of the VI instead of neatly arranged user interface portion of the front panel)

My suggestion:

VI should have three layers:

* User interface

* Data

* Block Diagram

Then you can edit your VI's data and block diagram all you want, and never mess up your user interface.

Data elements on the data layer don't need to have all that heavy 3D graphical representation where only borders of your nested data structures take up half a screen.

Each data element may or may not have graphical representation on user interface.

What do you think?

[RavensFan]

Then you might find this idea worth giving a kudo to.

We need to uncouple the "edit mode" FP size from the "run mode" FP size

[Yakov]

Just wanted to add illustration of what I mean:

[Mark_Yedinak]

I get the sense that you are using lots of local variables in your code. There really isn't a need for this feature since proper use of data flow and good architectures eliminates the need. Virtually all of your data can be contained on the wires. Passing data between parallel task is better achieved using queues/notifiers or action engines, LVOOP objects. If you need to see values when you are debugging then probes are available.

To be brutally honest I would not relish the thought of looking at the code associatedw with that front panel. I suspect it would be very difficult to follow and be poorly architected.

[A-T-R]

Hey Yakov,

you could very easily get rid of that unwanted behaviour that the FP displays the wrong section: Just integrate a SubVI that pushes the FP back to the "normal" view! I do that for all my VIs that have a GUI, I just set the "Front Panel Bounds" and the "Front Panel Origin" before actually displaying the FP by changing the "FP state" from "hidden" to "standard".

Therefore, for me an additional layer is not at all necessary...no Kudo here!

Regards

A:T:R

[Intaris]

I was initially going to simply refuse Kudos to this since the example shown doesn't convince me at all (and the uncoupling of the "Edit mode" FP from the "Runtime" FP would solve the cosmetic problem) but then just maybe.....

How many of us (and be honest here) have controls or indicators on some front panels which serve only as data repositories?  Of course making Typedefs out of the datatypes and using constants and shift registers instead would probably be a neater approach but I think the topic deserves at least a discussion.  But this only works as long as the controls and indicators are not on the connector pane.  I'm not 100% convinced it could not be a good idea but I'm certainly leaning to the "don't do it" side.

1) Is the practise of using controls an indicators like this to be tolerated at all?

If YES then goto 2) else goto 3)

2) Is there no way of somehow seperating the "UI" part of the front panel from the "Data" part of the front panel?  Maybe a docked "Virtual Front Panel" where we can drop indicators and controls as we like but is never shown in a running program.  Controls and Indicators on this panel whould be available on the BD just as any other controls.... Just thinking in a caffeine-free state so feel free to completely and utterly annihilate my idea if required (or just for fun...)

Is there any merit to the idea at all?

3) Kaboom, idea rejected

EndIf

[AristosQueue (NI)]

> Is there any merit to the idea at all?

Maybe. If we did this, I'd be tempted to do this in a way that discourages the local variables by having a separate pane just for items connected to the conpane.

[JackDunaway]

OK, I'm going to be the first to give Kudos to this Idea. It's a good idea, and to miss the merits by rejecting this idea based on the example is like throwing the baby out with the bath water.  

The Front Panel as it exists is overloaded to implement two types of interfaces: the interface between code modules (SubVIs) when coupled with the ConPane, and the graphical user interface (and there are two classes of GUIs: a UI intended for the final product, and a "SubVI" panel used as a development tool). (A third interface is as a "local variable" data repository, but that's just a design decision that typically can be improved, so it's something we're going to overlook for the scope of this conversation.)

This type of overloading is genius, uniquely LabVIEW, but not without it's quirks. Here's an example below of something that's always "felt weird" to me - having to define both a code interface and a user interface on the same front panel:

Sure, throw in an OpenG "Fit VI Window to Largest Decoration" as a solution, or maybe even formalize the definition of a run-time versus edit-time view. These are both useful mitigations of the weirdness of defining the code module interface on the same panel as the user interface, but they just don't address the root "funny feeling" (and actual productivity and workflow issues, such as managing two windows per VI, ensuring tabbing order only hits UI elements and not data interface elements, extra code/design to ensure the right portion of the window is shown in the final product...)

I'm giving this Idea +1 to raise awareness of the issue, although I'm not crazy about the suggested implementation of this idea (a third "Data" layer). I think a better implementation involves defining the Code interface on the Block Diagram - in other words, link the ConPane Terminals to the Block Diagram Terminals, not Front Panel Controls and Indicators. This change is both subtle and dramatic, because it allows things like an optional FP (only implemented when it makes sense, as either a debug panel or as a user interface) and data values integrated into the Block Diagram something like this. This idea has been brewing on my backlog for a while, tough to synthesize, but ideas like this help shape the puzzle pieces. Stay tuned (?).

PS - Totally would have given Kudos to this idea two days ago, just had to wait til I had time to write a justifying post. So, great idea springboard, Yakov - keep participating and making LabVIEW awesomer!!

[Intaris]

@Jack, this is exactly the kind of option I was thinking of also.  Nice Graphic.  Would need some obvious differentiation between the two areas, but essentially the twist I was trying to propose.

[Intaris]

@Yakov, I like this idea because it challenges the typical ideas we all take for granted with LabVIEW.  Although I'm not too amazed by your example, it's still an option which I think could have a radical effect on how we work with LabVIEW and could (as AQ pointed out) help discourage bad programming practices.

I've spent my kudos on this one because I personally think it merits a discussion (even if it's decided not to implement it).

[GregSands]

Here are two links to other related ideas that go along with Jack's comments (which I fully agree with):

Be able to link to the connector pane in Block Diagram

Sub VI without Front Panel

However I'm not kudoing this idea here, because I don't think an additional "Data Layer" is a good way to solve this issue.  I've compiled my thoughts into a new idea here.