LabVIEW Idea Exchange

Looking at messy diagram from forum posts (not mine!), I often find myself in a situation that I cannot really tell where an "interesting" wire is coming from. Triple-clicking just shows me a spiderweb of wire segments going in all directions.

Often, the leftmost wire end is near the data source, but not always. Maybe it would help if we could right-click on a wire and do a "find source" and a halo,(or donut or similar) would temporarily appear showing where the data in the wire is originating.

A wire can have many sinks, but only one source and the data source is the most interesting property of a wire.

A tool to find it quickly could be helpful.

This picture is way too ugly, but should give some idea.... 😉

Ther are 10 pages of suggestions coming up when typing "probe location on wire".

AFAIK, none of them addresses this irritating behavior of probes:

The probe icon will snap to some algorithmically determined location which might result in illegible data flow during debugging, or might end up in a region of the diagram far from where the critical action takes place.

I know that what matters should be the VALUE of the probe, but WHEN to check the probe value is also critical, and in a visual development environment, this time is determined by monitoring the data flow (among other methods). This is where this uncontrollable probe location can be annoying at times.

My suggestion: just as for labels, let the user choose the location of a probe anchor point on a wire (especially when it branches off).

The crux of this idea is a very simple premise:  Structures should not be allowed to hide code inside their diagrams.  Ever.  Period.  There is no legitimate reason.

The rest is implementation details which are negotiable, unlike the basic premise.

With Autogrow enabled this is not an issue.  So it could be as simple as removing the option to turn it off.  I would prefer a slight alternative, allow autogrow to determine two different behaviors when an object pushes against a structure boundary:  Autogrow = object wins and structure grows.  No Autogrow = structure wins and object no longer moves.  All structure growth is done by hand in that case.

When upgrading VIs which have hidden code, I suggest a one-time autogrow.  Breaking code could be an option ( ), but that would simply force the user to autogrow or cleanup the BD anyway.    If there are other errors, a broken run arrow is not a clear, direct indication anyway.

There could be a corollary preventing hidden code in general.  I may not agree with them, but I do see that there could be an argument there to allow hidden code in some cases.  That battle is being waged elsewhere:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-should-break-VIs-which-have-hidden-code/idi-p/2228268

I see no reason, however, to allow the bounds of a structure diagram to shrink beyond the bounds of its content.  Nefarious reasons? yes  Legitimate ones?  not that I can think of.

I empathize and support this idea as a start:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-a-structure-is-hiding-code-beyond-its/idi-p/2242866

But I do not want a visual indication, I want to know by construction that nothing lies beneath.

Anchore position of Bundle & Unbundle Ny Name elements to "Input cluster" and not to same point in the middle of element.

I don't like when I place (Un)Bundle By Name element to Block Diagram and when I connect Input cluster to same cluster wire then element dance on block diagram.

Similar: when you change (Un)Bundle By Name element by clicking a name terminal and selecting a name from the shortcut menu then element is dancing (moving) on block diagram.

Every time I have to shift (Un)Bundle By Name on block diagram to original position.

Expected behavior: Anchor (Un)Bundle By Name position to Input cluster part of element.

Second Unbundle By Name is reference of original position.

Second Bundle By Name is reference of original position.

Anyone building an executable in LabVIEW probably ran at one point or another into the situation where you exit the app, but the window stays open. So, you do some research and find out that you can call the Quit LabVIEW primitive () or close all the windows in the app to make it really exit. If you add the Quit LV primitive, you then probably encounter this - you test the app in LabVIEW, then when you stop it, LabVIEW suddenly disappears, requiring you to add code which will only call the primitive when you're running as an executable.

So, what if LV had an easier way of handling this?

Here are some options:

1. Add another primitive which will only work in EXEs.
2. Add an input on this primitive which will tell it to only work in EXEs.
3. Add a VI to the palettes which will wrap this primitive and allow the user to select when it's valid (default - only in EXE). That VI can also have an error input. This is the method I use today (the VI is in user.lib), but it would be better if NI shipped this VI.
4. AND MUCH BETTER - executables should exit by default when all visible VIs finish running. Thanks Randy.

By default, the mouse scroll wheel scrolls the block diagram or front panel vertically, CTRL+SCROLL scrolls through cases/events/sequences and adding the SHIFT modifer to either accelerates the scroll. In order to scroll horizontally, however, the mouse has to be hovering over the horizontal scrollbar. Because of the predominant left-to-right, top-to-bottom style of diagram organization, it would be excellent to have a more accessible way to scroll horizontally.

I haven't found anywhere ALT+SCROLL is used - I think horizontal scrolling is a good candidate to fill that spot.