LabVIEW Idea Exchange

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)

(This is an idea related to Jack's idea here, which however deals with "reshape array".)

When using "built array" with parts that are mismatched in lenght, the largest input wins and the rest are padded with the default value for the given datatype (zero for numerics). This is often not desirable, for example when graphing multiple plots.

Padding with zero causes extra data (zeroes) to show on the graph that did not exist in the original wires. A more desirable option here would be to pad with NaN so only actual data is graphed.

My suggestion is to add an optional input to "built array" that allows defining the pad value is case the inputs are mismatched.

Here is an example how it could look like. (of course the icon would probably need to change a little)

This has been discussed in various places like here, but I couldn't find an idea for it...

There are quite a few LabVIEW primitives which will always run, even if presented with an error on the "error in" terminal. Common examples are "Close Reference" and "Close File". 

What would be really useful is to have some kind of visual indication of this behaviour. Ideally this would be a simple marking on the VI icon which could be easily replicated by LV users when we create such VIs ourselves. (It could possibly even be an option in the icon editor!)

Currently the only indication that a VI will run on error is this discrete line in the VI help:

I believe a visual indicator would be much more fitting for LabVIEW as a visual language, and would make this behaviour far more obvious to LabVIEW users.

This is a very small suggestion, and hopefully easy to implement.  When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires.  All I'm asking is that Error wires are always placed underneath all other wires when they are created.  To my mind, this improves the readability of the diagram.

What would help further is if Error wires were "faded", as if they were 50% transparent.  You do need to be able to see them, but not such that they stand out.  But I'm much less certain that such a change could happen.  The khaki color is an improvement on the old pink though, that's for sure!

Add new features, flexibility, and new controls to the Front Panel.  The only new controls I've seen were made by LabVIEW Customers, and although they were great, they were not resizeable without being distorted (bitmap).  I think it's time for NI to give more options and features for the Front Panel Controls.  I attached some suggestions.  They are there for example, so don't focus on the controls I've made, but the idea of improvements I am suggesting.  NI has done a great job on the Diagrams.  I should hope it's time NI improves the Front Panel.

I have a rather large string indicator for displaying operator messages/alarms

and I would like to have the option for an automatic vertical center of the text,

so that all messages get displayed in the center of the screen (if too many lines, justify to top and display the scrollbar).

I also have a 2 line statusbar, but displaying a 1 line message that is not vertically centered, looks very strange.

The work-around I'm using now is to display the multiline string centered in a picturecontrol,

but I'm not a big fan of this fix because there are many boundary-conditions to keep in mind ...

Another annoyance is that to prevent selection of text in the indicator I often disable the indicator

(it looks unprofessional if an indicatortext can be selected in the GUI),

but if the displayed text is larger than the string indicator, the scrollbar is also disabled !?!? 

and therefore not controllable by the user

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes).  This one item would expand the UI possibilities.  It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets.  Below are some industry examples:

Adobe Splash Screen (No border, has shadow, not square)

  Microsoft Word 2010 Splash Screen (No border, rounded corners)

 Resource Meter Windows Gadget (No border, specialized graphic)

Windows Media Center Gadget (Empty-transparent space between two UI elements)

The State Diagram Editor was a very cool tool and lots of LabVIEW users (not only beginners, far from!) are missing it!

And no, the state chart module is not a replacement for the State Diagram Editor!

Discussion here.

Image borowed from Ben

Have you ever placed a background image on your front panel to make it look good, but then found that most of the controls and indicators covered everything up?

Ever wish LabVIEW had more appearance customization to make better looking GUIs?

I would like to propose an opacity slider control in the appearance settings tab of front panel object properties. The added setting would not make the entire objects opacity change; ideally the opacity control would only affect the borders and grey space. With this added control users can make better looking user interfaces without having to make custom controls.

Take a look at the difference:

Not Ideal Front Panel with background image and NO Opacity Control

Beautiful Front Panel with background image that you can still see by setting Opacity Control to 50%

Before and After Appearance Settings tab in the Properties Window for a waveform graph:

Currently the only easy way to implement a similar type of setting is go fully transparent by using the tools palette paintbrush tool and setting the color to transparent:

Kudos and share this idea if you want it to happen!

Hi,

i propose to add a "Key Focus" event for each control. We already have Mouse events (leaving, entering) - but when the user (or the programmer) prefers the keyboard (with proper tabbing setup) you have to poll each interesting control for it's "Key Focus" property to initiate a user event...

So please:

Add a "Got Focus" (and additionally a "Lost Focus") event to the event structure!

This recent idea reminded me of something I have wanted for quite some time now:  the ability to determine if a property is read or write based on wiring, not some half-buried option in the right-click menu.

The basic idea is simple:  all properties have two terminals, one for writing and one for reading (except read-only of course).  No right-clicking, just wire up the direction you want.

The bottom case is a bit interesting.  I see a few possibilities:

1.  Passthrough (cosmetically saves branching, crossing, etc.) Same behaviour regardless of errors.

2.  Read then write : returns previous value.  What happens if there is an error?  Passthrough, old value?

3. Write then read: almost always passthrough.  In case of error would it return old (ie. actual value) or passthrough?

4. Do not allow this.

I would expect it to perform the write and then the read (3) or passthrough (1).  What is more important to me is the actual value and not the intended value.  Mentally I just see data flowing into then out of the PN when both are wired. 

Bottom line:  I see no reason not to permit the wiring to determine read or write of a property.

If there is a cop-out lack of consensus and simultaneous connections are not allowed, I would at least ask for a keyboard modifier (say shift) such that I can shift-drag to expand the PN and get the same property repeated instead of going down the list.  Then I could at least do the write+read with a lot less mouse movement.

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.