LabVIEW Idea Exchange

This drives me crazy...  I've noticed that if I have some code on my block diagram (or controls on my front panel) the scroll bars indicate that there is more stuff outside the view of the window that can't be seen.  It would be nice if the scroll bars only activated if there was actually code outside of the screen to be found.  Every time I see this, my OCD kicks in and makes me try to move my diagram to show the hidden code, only to realize that LabVIEW is just messing with me...

Of course an image is worth 1024 words..

Today, if we want a FOR loop with a fixed number of iterations, we need to wire a diagram constant to N. We could probably save a few clicks if we could click on N and type in an integer directly. It would also unclutter the diagram. This should of course only work if N is unwired.

Of course the N-Box would grow to the right to accomodate all digits

To later change the loop back to "normal", we would type N into the box or simply wire something numeric to N from the left.

As an example how it could look like, here's a simple cross product implementation (Yes, I know, LabVIEW already has a cross-product, so this is just to show the idea!)

Top: current implementation

Bottom: Same code after this proposed idea has been implemented

The default LabVIEW environment option should not show terminals as an icon. 

Sometimes we have a need to do some mild synchronization between otherwise parallel tasks. Typically we would use a flat sequence (but there are also exceedingly fancy tools such as "Rendezvous"). Even a flat sequence is often overkill for the given situation: It is a 2D object with it's own diagram and input and output tunnels. We need to decide what should be inside and what should be outside.

I suggest to extend the idea to a 1D object: The "Synchronizer Bar". It is basically a flat sequence with zero frames, condensed to a single vertical line (Maybe we could even allow kinks in it???).

The function is very simple and immediately intuitive (as anything in LabVIEW should be!!) and can be described in a single sentence:

"No data can leave any of the tunnels until all tunnels in the structure have received data."

Ideally, we should be able to "free-hand draw" this structure interactively with the mouse and a tunnel will be automatically generated for each wire we cross.

Here is a dumb (but illustrative) example (ignore the code itself). That's how it could look like.

(At the moment I simply merged the edges of a flat sequence, but I am open for prettier suggestions ;))

Overall, it should be closely related to the flat sequence and include certain right-click actions (e.g. Add frame before/after, which would expand it into a flat sequence).

All events have optional event terminals on the left. Signaling events also have e.g. a "discard?" terminal on the right.

Hovering over them with the mouse does not generate any relevant context help, and maybe it should. (well, there is a tip string that simply duplicates what is already written on the terminal giving boring redundant information).

I suggest that hovering over an event terminal with the context help open should first of all tell us how these terminals are called in general ("Event Data Node", according to the help, but who knows that???), but also give specific information about each terminal under the cursor.

For example:

• if I hover over the "discard?" terminal, it could tell me that wiring a TRUE would ignore the event, etc.
• if I hover over the "Ctlref" terminal, it could tell me that it outputs a control reference of the control that fired the event
• if I hover over the "type" terminal, it could tell me a list of possible types and what they mean.
• etc.

IDEA: I suggest to add relevant context help to all event data nodes. Thanks!

(Note that e.g. the "timed loop" terminal already have context help. This should be similar)

Same information as the '\' Codes Display but easier to read.

Tools like Word and Notepad++ allow you to view the hidden symbols in a string, it would be great if LabVIEW did as well.

Normal Style

'\' Code Style

Symbol Style

I wonder if newly created wire labels should inherit the wire color for better clarity. Labels on array wires (and other thick wire thingies, clusters, objects, etc) could go bold for the same reasons.

(Of course the programmer can later freely change these label text properties)

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

All property nodes should use enums to make the code readable and not required to open help every time you need to set a properity.  I find myself creating typeDefs for my self so I don't have to look up what the properity does and to make my code easier to edit.  Example provided is to disable a control on the front panel.  This is in the LabVIEW style guide