LabVIEW Idea Exchange

I would like to introduce a little shorthand for creating numeric constants with non-decimal radix.  New constants should be able to autoadapt for radix, much like they do for type:  Drop a constant, enter '0x20' or 'x20' to get a constant with Hex radix (visible!), and the proper value.

In addition, it would be nice if automatic conversions would take place if radix specifiers are entered into (non-hex) constants (or controls).  For example, entering '0x20' into a numeric control with decimal radix should result in a value of 32 being entered (auto conversion).  Hex is an exception, obviously, because b and d are already valid.  The other radices have no such problem.

I always wanted to have a table or a (Multicolumn) Listbox that allows me to integrate drop down menus (or other elements)

Here's an example from another software (Agilent Benchlink datalogger) which illustrates this quite well:

One could realize something similiar by creating his own Array of cluster, but this is cumbersome and very uncomfortable to change/maintain, mainly because of the difficult selection of all the control frames which are placed one over the other...

Functionality good, layout questionable...             Layout similar to the picture above, but not very flexible (not an array) and "hard to handle"

PROPOSAL:

Add a new type of list control, behaving similar to a Array of cluster control, where different types of already existing controls can be selected as it's elements, and where those controls are placed next to each other without those annoying and real-estate consuming spaces between them

A-T-R

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.

I'm not sure if this idea already exists, at times i wish to have an option to display the line numbers in a string control/indicator/constant.

The compare tool is fundamentally broken which is somewhat shocking considering that such a tool is essential to any sort of large scale or long term software development.

Attached is a basic LV 2023 example which illustrates some of the many flaws with the tool.  If you compare "old version" and "new version" vi without including cosmetic changes, the tool shows 33 differences, most of which are incorrect.

A great time saver would be if we could drag or click to switch connections directly in the connector pane instead of having to disconnect and reconnect controls.

This can be a simple two click process:

If there's already another control\indicator where you click, they get switched.

Title says all. Can't believe it was never proposed; if it was, I couldn't find.

Missing that, I have to that programmatically, but it's always a detour:

Should be quite easy to change the property page like e.g:

(6 colors for system booleans, 4 for all others, as known)

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!

In line with giving us a better polymorphic VI editor, doing the same for Enums would be great.  The current implementation is SSSLLLOOOWWW and unwieldy.

Please re-visit this functionality to make our lives easier....  So many people create enums via rings for exactly this reason.  This is just unneccessary.

Hi,

There are numerous ideas floating around about where the color box constant and control should be located in the palettes. How about if there wasn't a distinction between a color box and its numeric representation? Like the "View As Icon" option on terminals and clusters, I suggest a "View As Color Box" on numeric constants and controls/indicators:

I'm undecided on if this options should be available for all numeric data types, integers only, or U32 only, and what should happen to the Representation options when the numeric is a color box. I see at least these options (ordered after my preference - I prefer 1) the most):

1) The "View As Color Box" option is available for all numeric data types, but when selected the data type changes into U32. If you change Representation to anything else but U32, the "View As Color Box" option is automatically deselected.

2) The "View As Color Box" option is available only when the numeric is U32.

3) The "View As Color Box" option is available for all numeric data types, and coercion happens between the selected "color value" (U32) and the true Representation of the numeric.

Several ideas would be fixed by this, for instance this and this.

Cheers,

Steen

Whenever we create a constant (or control) on a partially connected function, we get not only the same datatype (good!), but also the same array dimensionality (often not so useful).

In the vast majority, I want do do some uniform operation on the entire array, so a scalar control or diagram constant would be much more desirable. I usually end up creating the array constant, then pulling it out of the container, hook it back up, and delete the container. This guarantees the correct datatype (I32, DBL, CDB, etc).

(It is even more tedious to place a diagram constant from the palette and then remember the datatype and adjust accordingly).

IDEA: 

When creating a control or constant, and it would result in an array, I would prefer to also have a scalar option.

This little move illustrates it in the case of creating a diagram constant. It should apply equally to controls.

I'm developing code, and like most people I know, I have multiple VI's open at once.

If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption.  I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog. 

like this:

Problem

Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.

Idea

I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

Right now, if you happen to use the right colors, LabVIEW will change the text color on a Boolean.  But, if you don't pick the right colors, LabVIEW keeps a single text color.

This would probably be fine IF LabVIEW allowed you to have multiple text colors, but you can only choose one:

But, as you can see, LV only supports one text color.  I propose that LV support two text colors (ON and OFF).  Obviously LabVIEW has the ability to change the color already since it will do it in the right circumstances, but it would be nice if LV gave us control over it.

In my use case at the moment, I am trying to make a custom illuminated button which the text on the button should be grey went off, and yellow when on.

When a project file has been changed, you can view a list of the changes that have been made to the project when closing it. Unfortunately, these changes often lack important details.

For instance, the most common change I make to project files is adding or removing items (even if inadvertently, such as opening a new VI and then immediately closing):

However, the message doesn't indicate which item was added or removed.  Usually when I'm looking at this window, I want to know specifically which item was added/removed so that I know whether or not it's important to save the project file or if I accidentally added something that I didn't want in the project (or removed something that I did).