LabVIEW Idea Exchange

We've had a few recent discussions relating to labels of block diagram objects. I don't think the following came up yet, but I think it's one area where improvements are really needed.

If we create a property node or invoke node, it has a label indentical to the linked object. However, this label can be changed to anything we want, possibly leading to code that is very confusing! For example if we had two terminals labeled A and B, we could label the property node linked to A with "B" and vice versa, completely obfuscating the code!

(The beginner could also incorrectly assume that changing the label is the correct way to change the association to a different terminal)

These nodes should really have the label of the linked terminal hardwired to the corresponding terminal name, because anything else simply would not make a lot of sense.

My graphic is not as nice as Jack's here, but I think the idea is clear. It would certainly need a few tweaks from the art department. 😉

We might need an option to hide the label. Oversized labels should be truncated for display, only showing the full text when hovering.

Important disclaimer: I am sorry, this is not my original idea, because it is (together with many other nice features!) already implemented in the LabVIEW UI builder. Credits go to the relevant NI developers.

This Idea posted here tries to see how much interest there is in such a feature and to show support that we want this also implemented in plain old LabVIEW. Personally, I really like it! 🙂

(It is also somewhat related to this idea (but probably not a true duplicate), especially my comment there already exapands on the idea!)

The Unused Items Tray (see also e.g. Christina's Blog entry) is an area on the diagram that contains terminals or FP objects that have not yet been manually placed or are currently only "used" on the BD "xor" FP, i.e. not on both.

The current problem in LabVIEW is that if you place a new control on a complicated VI, the terminal will end up on some random place, typically piled well camouflaged on top of some other diagram structures and possible a scroll away from where it is actually needed. Similarly, if we create a control or indicator from a terminal on the diagram, the control will typically be outside the carefully placed visible area and there is no way to grab it without first messing up the FP alignment by either scrolling or enlarging the window.

In all these cases, it would be nice if the objects on the "other" window would land in a predictable reserved floating location for quick and easy manual placement where they belong. During development, there are probably a few terminals that are not yet used or connected, and we should be able to place them back into the unused items tray of the diagram so they never scroll out of view or get misplaced.

On the front panel, we might have some spare controls "parked", and they would not show in run mode at all. This could even be abused for "local variable zombies" (=hidden controls with the sole purpose of making a local variable) along these lines, which might be OK (=better than hidden controls!). Front panel items in this tray would look like their palette entries. We don't want e.g. full-sized graphs in there!

Now, how should all this look like? In order not to cover valuable diagram space, it should be something that collapses to near nothing when not used and would only expand to show the current contents when hovering or clicking in a special area. Of course there should also be an option to pin it open. When minimized, it should look different when "not empty" vs. "empty".

Problem:

Lets say you're writing a VI for stopping a process. Wanting the icon function to be recognizable at a glance, you open the icon editor and go to glyphs looking for this:

You type "stop"... nothing... hmm. After muttering a few curses, you either trudge through the whole icon library, or you draw one.

Turns out you should have written "abort"! Oops. Not really intuitive.

Solution:

Turns out the glyph search is fairly useful. It can see if your search is in any part of the glyph file name. If the above glyph was named "abort stop.png", the search would have succeeded.

Glyphs would be a lot easier to find if they contain the noun and a handful of verbs that they represent. For example:

"support.png"   -> "support checkmark yes.png" (support?)

"keep.png"     -> "keep checkmark yes.png" (keep?)

"create.png"     -> "create new.png"

"file.png"         -> "file disk save.png"

Alternate Solution:

Impliment tags into the glyph library with the ability to add new tags to current glyphs. This would avoid long file names.

Give us the option to input a Hex RGB code in the color palette.