LabVIEW Idea Exchange

This is a small thing but it drives me nuts.  Whenever I place a case on the diagram, I always need to move the case seletor up or down so it aligns with the source output that will be driving the case.  But, the newly placed case always has the seletor right in the middle of the left side.  This is also where the drag hover control (?) is located.  I seem to at least 50% of the time grab this drag control when I want to grab the case seletor and move it.  If the selector was just placed above or below the middle of the left side, this issue would go away.  I suggest placing it 1/4 of the way from the top, since most of the time the source of the selector is above the midpoint of the case block (at least in my code).  YMMV.

I know it is a nit, but it is low hanging fruit to fix and it is annoying.

A couple of recent ideas regarding the VI Hierarchy window are good, but do not go far enough, in my opinion. I would like to see the VI Hierarchy window annotated with a lot more status information about VIs, including:

• A glyph showing if Execution Highlighting is enabled
• A run arrow on any VI that is running top level.
• A path from the top level VI through any currently executing subVIs (the path may be forking as there may be multiple subVIs running in parallel)
• That path would have temporary lines going to VIs that are invoked using the Call By Reference node (as opposed to reordering the hierarchy tree to put such VIs as subVIs of the caller)
• A glyph showing any VIs that have breakpoints on them and a different glyph if the VI is actually stopped at a breakpoint.
• Reentrant clones of VIs, so that call chains can actually be seen, including the ability to double click on a particular reentrant clone to open its front panel
• Any other execution state information that can be easily expressed as glyphs and highlighted connections among VIs and/or other file types shown in the hierarchy window (open to brainstorming).
• Whether debugging is enabled or disabled on each VI

The VI Hierarchy window has already been updated in LV 2009 and 2010 to show all the connections among different files and resources. Finishing it out to show the full state of the system would make it a powerful debugging tool.

I've been using block diagram cleanup extensively over the past year in an attempt to speed up my LabVIEW programming.  I am definitely faster as a result of using the feature, but there are still some VIs that I have to arrange myself, because diagram cleanup's arrangement is unacceptable.  So the feature still has a ways to go in making all my diagrams acceptably clean.  It's my understanding that there are many more configuration options in diagram cleanup that could potentially be exposed to the user, but I think an easier way to conform diagram cleanup to my standards would be to point it at a folder of VIs that I have personally deemed "clean", and have diagram cleanup mimic the arrangement in those VIs when cleaning up other VIs.

As an example, I am ok with input tunnels into a case structure overlapping somewhat, if those tunnels are coming straight from subVI output terminals that are close together.  Diagram cleanup insists on adding space between the tunnels so that they don't overlap, which results in unnecessarily crooked wires.  Ideally, I would have VIs in my "clean" folder that have slightly overlapping tunnels, diagram cleanup would discover that I'm ok with this, and subsequent cleanups would allow this arrangement.

Traditionally LabVIEW has treated Strings and Unsigned Byte Arrays as being the same. This is nowadays a little unfortunate as all UI systems use some kind of encoding so Strings are not generally interchangeable with Byte Arrays anymore.

In trying to stay for binary data as much as possible with Byte Arrays instead of Strings, since that would be the sensible thing to do, the Unflatten from String (which should rather be called Unflatten from Stream) puts a totally unnecessary wrench into this.

I always had hoped that LabVIEW would change the default binary data stream format to a Byte Array at some point but this while it would be possible, is a fairly pervasive change that would require many backwards compatibility decisions that I unfortunately don't see NI going to spend time on anymore. This change however would be a very small change that has zero backwards compatibility concerns and almost no work to add to the existing LabVIEW software.

This same change has been for instance made to the TCP Write node some versions back already and could be also applied to the VISA Write!