LabVIEW Idea Exchange

Format Into String can become very complicated when you have multiple inputs. I think implementing it in a way similar to the Formula Node could make it much better.

Ideally,

1. naming of the inputs should be allowed
2. the input fields in the string should be color highlighted
3. when hovering or clicking over any of the input or the format string fields, the matching ones should be highlighted in bold or with different background for example.

As a side note, the Formula Node itself could also benefit from the same color and hover highlighting.

Is LabVIEW available for Android based systems and other touch interface systems.If not how about using LabVIEW for mobile measurements using these systems.

It would help a lot if we have an option called pause on first Error. So that the VI at the node/primitive that generates the error and highlights that node so that user decides to continue or abort.

Have you ever created a cluster like this?

I have. Numerous times. It's fairly easy to create clusters which get out of hand. The magic number is usually around 10-15 elements, assuming some of them are clusters as well, but even if those numbers are manageable, I've also created larger ones, and those aren't manageable.

Using LVOOP mitigates this to some degree, but does not solve it completely.

So, it would be great if we could divide the cluster into "pages" or "categories":

This will allow us to logically divide the cluster into manageable areas.

The names of the pages will appear in the selection list and in the unbundle node, as shown in the example (although you could hide them in the node by unchecking the full names option), but they will NOT actually be part of the element's name. Changing the name of a page or moving an element from page to page will NOT require you to change code which already uses that element.

Notes -

1. In my mockup I used a tab control. I understand that LV R&D has some aversion to the concept of tabs inside clusters, so I would like to make it clear that I'm NOT asking for a tab inside a cluster. This is purely a cosmetic and organizational feature.
2. I already posted this as a comment on this idea, but I figured it was worth posting as a separate one.

For those of you who haven't signed up yet, you should go and have a look at the Next Generation LabVIEW Features Technology Preview (a mouthful, but in short, it is a UI and Development Environment demonstration version of what NI is cooking up for future versions of LabVIEW). There are some cool things and some downright awful ones.

One of them has been sneaking its ugly neck in LabVIEW 2016: reduced contrast. I am (my eyes) getting tired of it. A few examples of the changes introduced in 2016 are shown below:

2015:

2016:

Considering that the trend is for displays to not increase that much in size but increase in resolution, we have now to factors to fight against: the reduction in size AND the reduction in contrast. I won't mention laptop displays going in economy mode and reducing their luminosity, but the point is that it is making LabVIEW even more difficult and unengaging to use. Way to go to loose any chance to attract new users, and run the risk to loose old timers due to added eye strain.

Put simply: Restore high contrast icons  and please, do not go ahead with the washed out IDE and UI objects showcased in Tech Preview.

At present, build paths in build specs are stored as absolute paths, unless the path happens to be in the same folder as the project. Relative paths that are a level or more up from the project folder are not supported. Modifying the XML directly does not support relative paths either.

When working on multi-developer projects, where source control root folders may be different, this can be a serious annoyance.  One of the better workarounds at the moment is to build to a non-desired relative path (within the project folder) and then to run a post-build action to move the generated files to the desired location.

But it shouldn't have to be this way -- relative paths should just work.  (They are supported elsewhere in projects, such as with dependencies.)

(Note: this is the follow-up to a post on the LabVIEW forum about the same issue.)