To conserve the real estate, can we alter the controls/indicators to have labels "on" them. In that way, we can save the real-estate. The controls and indicators could have the auto-size feature if the labels need to be longer. This would make it cleaner.
By not having a seperate location for label, I believe you do save space.
Sure, I made my box bigger to depict the idea, but keeping the height of the controls/indicators in the block diagram the same, and embedding label within it ... We should save space 🙂
I'm too lazybusy to search right now, but I'm pretty sure this has been suggested already.
Like RavensFan, I'm not seeing the savings because you lose data type. Maybe a better picture would help.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Great image Jack (from your own old idea), but why not a step further? Current locals and globals do without type glyph but rely solely on color coding. I propose an even more compact terminal:
Why even differentiate between locals and the terminal at all? What about just having a Local, that can at leisure be tied to zero, one or multiple FP controls (some of this has been suggested before in various posts).
Just to clarify what I mean with tying a "local" to multiple FP controls/indicators; All the controls/indicators tied to the same "local" should of course data-wise be equivalent, and could be used to echo the same data on several places in a GUI, as well as allow for controlling the same value from several different positions within the same GUI. Turn one knob and the other knobs turn as well for instance...
A "local" tied to no control/indicator would be a true variable in the BD only - like a VIRegister.
So we could basically just have these two options for variables:
> Why even differentiate between locals and the terminal at all?
Locals and terminals may be functionally the same, but there is a big difference between a VI that only accesses a control/indicator in one place, and one that accesses it in multiple places. The latter breaks dataflow and is harder to read and analyse. Since most subVIs should be written only with terminals, I prefer to have the presence of local variables made very obvious, so it is immediately flagged that I have to look at this subVI extra carefully (and worry about the possibility of race conditions). Local variables should be rare; making terminals look similar to locals means I can easily miss the subVIs that are doing something non-dataflow-standard.
@drjdpowell: Agreed you break dataflow whenever you write to a register-type data storage (whenever you leave the BD if you will). But sometimes it's necessary to communicate without dataflow (TCP/IP for instance), and sometimes a single non-dataflow communication channel can make the rest of the program much simpler (events and queues are common methods). And sometimes a local is the best way to share a "common register" between two otherwise non-dataflow-dependent pieces of code without having to blow those two pieces of code way up (two parallel loops for instance). In the locals-case racing and missed values may be unimportant (or else you program around that, by using a queue instead for example). And on Real-Time you don't want to use the terminals for writing at all, except when your subVI ends.
I'm not advocating more locals, I'm merely proposing that there oughtn't be this destinction between the terminal and its locals.
For sure there is a destinction today between the terminal and the local, when we consider the transfer buffer and FP update for instance, but I look further ahead. At the nearing point in time where the necessary severing of the BD entirely from the FP will happen. At that point we will have to actively bind "registers" in our code to the GUI elements of choice - or it will more likely be network-publishing of certain data values, which will then be receiveable either in a local GUI, a remote webpage, or both simultaneously.
So, to recap, I'm not more pro- or con-locals than before, I'm just asking if it wouldn't be simpler to not make a destinction between terminals and locals. All current differences are made up and unnecessary anyways .
