LabVIEW Idea Exchange

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

Start wiring the new error, then click on the merge error node.

LabVIEW expands and connects the error wire

This would also be nice for any expandable node like build array, concatenate strings

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

For as long as I can remember (I have used LabView since 4.0) the decorations and contropls pallette have remained unchanges for the most part.  End users want an application more like the iPhone than windows98.  We need a new decorations capability to be able to customize controls  to a high level.  The square circle and triangle of 2 colors and flat or 3d/rounded nolonger cuts it.  I would like to see a new type of decoration.

- Decoration made of vector graphics so it is scalable, user can add or remove verticies and move them around to make new shapes.

- Labview native color pallet linked to item colors (default can be 2 color option of FG, BG but scale this to an array of colors to make more complex decorations)

- Colors add transparancy and alpha channel

- Grouping allows building of a single new decoration from several  primitive shapes.

- Decoration possible support gradients (color blending)

*** Decorations should have optional labels so that they can be addressed programatically

-Decorations added to customized controls that have lables associated with them become part of the control and can be accessed via a property (ie can be set to not visible through a property node)

I know this is asking quite alot, but I have found that when I make my applications not look like LabView (and it is easy to spot a LabView application) it is not a well recieved as when I present a highly customized application that does not look like a labview example.  Allowing the community to easily create very professional looking new controls and indicators will do wonders for our GUIs.

I really like the new arrow feature with block diagram comments.  But in many cases, I have a comment that applies to more than one BD object.  So, I would like the ability to link my comment to multiple objects instead of just one.

This would allow me to turn this:

into this:

Thanks!

-John

Using "Fit control to pane" and the "Scale Object with Pane" options it is now relatively simple to build front panels that scale the way users are used to from other applications - however there is one shortcoming that it is easy to run into: cases where you want a tab and (some of) the controls (a table e.g.) on it to scale with a pane.

Getting the tab to fit and scale is a done deal, but then comes the scaling of the objects on the tab...

The option you have today is to fit the controls on the tab to the pane...however that does not give a proper behaviour because then they grow larger than the tab they are on. Objects that are set to fit and scale to the pane should basically use the tab as their "pane" - not the pane the tab is on.

Instead of having to open the "Display Format" window everytime you want to drop a control/indicator/constant with a special format value (i.e. 2400000000 as 2.4G) make the control/indicator/constant automatically set to whatever format you put in. For example

Typing in 2.4G sets the Display Format to "SI notation".

Typing in 2.4E9 sets the Display Format to "Scientific"

Typing in 2400000000 sets Display Format to "Automatic formatting" etc

Wire a Case Structure with an enum. Now pop up on it and select "Add Case For Every Value." In today's LabVIEW, this adds new frames to the structure so that every enum value is handled by a unique frame. This makes creating the structure initially easy, and it gives you a way to walk through and make sure that you've filled in code for every frame. But today, the Case Structure has includes the "Default" case when the Case Structure is first wired. That is done so that wiring a Case Structure with an enum does not result in a broken VI. When a programmer provides a unique case for every value, the Default state is now redundant, and the only thing it does is create the potential for error if you ever add to the enum. Thus I would propose that if you use "Add Case For Every Value", then LV should remove the Default tag from the first case.

Once in a while I encounter a case or event list that forces me to grow the structure

- in order to keep the list readable:

It would be nice if the item-list would automatically "wrap" instead.  

I like to collapse long string and path constants to consolidate diagrams.  Showing the string or path value in the tip strip is useful but tedious to update.

I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.

This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.

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.

As shown by below RG code, the Select function should be redesigned in order to align the s input with the output vertically. Currently, the input is too low.

Has this ever happened to your application?

Well, it happened to me many times. I never figured out when this happens and when it doesn't, but I do know of a certain way to disable it - add the line HideRootWindow=TRUE to the application's INI file.

The problem with that solution is that when you build a new EXE, LV creates a new INI file which overrides the old one, unless you explicitly create your own INI file and tell LV to use it.

So, the solution to this is simple and this is the idea - LV should add the line HideRootWindow=TRUE to the application's INI file by default. Problem solved. Alternatively, maybe the whole root window thing is not needed anymore and NI can simply get rid of it.