LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

 

constant tip strip.jpg

 

 

 

 

 

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

 

properties window.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

options window.jpg

 

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:

2017-09-28_11-42-52.png

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

LabVIEW_2017-09-28_11-02-36.png

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

 

 

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:

 

 benchlinkdatalogger.PNG

 

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"

arrayofcluster.PNG         SingleClusters.PNG

 

 

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'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.

 

Line numbers

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:

 

Switch Connections.png

 

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

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!

Wouldn't it be nice if Probes window had a drag'n'drop reorder functionality, maybe even a Sort?

 

Often you (I) place a couple of probes, maybe add some in another VI and then go back and add one earlier in a block diagram. 

Is this a problem? Well, it's not breaking, but i'd like probe 1 to be the earliest executed probe and so on. Often execution order can easily be something like 13, 19, 3 and drag'n'drop #3 below the #19 would the shift them as 3, 13, 19. (Similar to how Reorder Case works)

 

It'd be nice if you could drag this probe in the probe window and it'd change numbers accordingly (switch/reorder within the VI).

Maybe even have Sort button that simply renumbers all as they're shown in the probe window.

 

 

It's somewhat similar, but different, to Altenbachs switcheroo idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probe-switcheroo/idi-p/3126138

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:

 

ViewAsColorBox.png 

 

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

I like to hide the Index on array constants if all elements are shown and show index if the array is larger than shown (and scrollbar if much larger). Wouldn't it be neat if this was automatic?


All elements shown; hide Index

Yamaeda_0-1720018030064.png

 

More elements in array than shown; show index

Yamaeda_1-1720018092693.png

 

Several more elements in array; show index + scrollbar

Yamaeda_2-1720018272585.png

 

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.

 

Enum editor.PNG

 

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.

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.

 

 

Message Edited by altenbach on 07-11-2009 09:51 AM

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:

 

vipropertiesdialog.png

Currently if you flush an event queue that data is lost. Flushing and destroying and event queue should have the same interface as flushing/destroying a normal queue. Return the Data! I want the option to batch process the events, The code below would have to handle 1000 separate events to get the data out.


hunter_jki_0-1672775860961.png

 



Idea
Flush Event Queue.vi should return remaining event data.
Destroy User Event.vi should return any unhandled events.

For projects, libraries, and their associated files, if the "Save Version" property is set to an earlier version of LabVIEW, the project and its files are not recompiled to the editor version.  There should be an option on the Mass Compile dialog that allows the "Save Version" property of projects, libraries, and classes to be overridden.

 

smmarlow_0-1745952830273.png

 

 

.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors.  Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:

 anchor1.png

 

Would be resized into:

 

anchor2.png

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

 

Control auto numbering.png

 

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

Cluster Size as a Wired Input:

 

  • Easier to see
  • More implicit
  • Nearly impossible to forget to set it (if it were a required input).

 Cluster Size.gif

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.

 

Boolean Text.png

 

 

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

 

Boolean Properties.png

 

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.

I tend to use malleable VIs more often than half of the items in the "New" context menu list when you right-click within a project, however, it's not an option:

_carl_0-1635193396358.png

Instead, I either need to:

- Create a new VI and then make several property modifications, and save it as a ".vim".

- Create it through the file menu and then remember that I need to move it to the appropriate place in my project, because it gets created at the top-level.

 

Why not include this in the context menu?  (Bonus points if Polymorphic VIs get added too!)

 

Current it is very hard to reliably manipulate decorations using VI server.

 

LabVIEW need to be able to create explicit decoration references (like it is possible to do on other objects through right click Create>>Reference).

 

Decoration Explicit Reference.png

 

Note: Thanks to TonP for the idea.