NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea
Yamaeda

Mark selected Connector pattern

Status: New
by Trusted Enthusiast on ‎11-24-2014 06:09 AM

(Unless it's already changed in newer LV's, i'm on 2011 right now)

 

When opening the connector pattern, the current isn't marked in any way. If i'm after some extra connectors or a symmetrical one (why do people choose 3-1-1-1?) it'd be nice to quickly see where to start looking. A simple bold outline would suffice, maybe in blue?

 

ConnectorPane.png

 

/Y

I am taking advantage of the recent FileVersionInfo to pull up the Version Number of the Executable at Run Time and display it for the User (who can then call me and say "Version 2.1.3.4634 crashed", and I can figure out which source this was).  I take advantage of the Pre-Build Action to create the Version Number, taking the "Build" part from the Revision Number of the Project itself (since the Pre-Build Action gives me the path to the Project, this is fairly straight-forward).

 

However, in order to get the correct Build to appear in my Executable, I must build twice.  The reason for this is that LabVIEW apparently reads the Version information before executing the Pre-Build Action, so my attempt to set it to the "correct" value is ignored until the subsequent Build.

 

Personally, I think it is illogical to have a "build Action" that silently takes place before the user-specified "Pre-Build Action", though there may well be a hidden "good reason" for this.  I would like to request, therefore, that LabVIEW include a "Feature" that specifically allows the Pre-Build Action to include not only setting the Version Information (which it currently does) but allowing this updated Version Information to be used in the current Build.  True, the work-around of "Build Twice, Use Once" works for me, but why should we need to jump through this particular (unpublished and unexpected) hoop?

 

Bob Schor

I have the hadit of pressing Ctrl+Shift+S (Save All) which is annoying while working with Read only VIs. We always get a pop-up enabling us to save the VI in a different place or with a different name. As a result we get the browse window to Save the VI with a different name or in different path. This happens on clicking OK (which make sense) but also on click Window close button/ESC key

My suggestion is to continue the save operation only on clicking OK and abort the operation when the user click the window close button/ESC key. This would be more meaningful and would make more sense to the way the Save operation is handled.

I am also fine with adding a Cancel option along with the OK button.

 

AbortSaveOperation-1.PNG

 

AbortSaveOperation-2.PNG

 

Mike_King

HTML/CSS UI elements

Status: New
by Member Mike_King on ‎11-18-2014 12:19 AM

The web is miles ahead of LabVIEW for its UIs.  LabVIEW should support embedding HTML5/CSS containers as content for VI front panels, that can be bound to any data type or class preferrably to enable more capable UIs.

dan_u

Filter dependencies from "Find Items with No Callers"

Status: New
by Active Participant dan_u on ‎11-13-2014 07:17 AM

"Find Items with No Callers" could be a useful function on the project, but currently most items it reports are in Dependencies. Why is an item even under Dependencies if there is no caller? It seems if I call one function from an .lvlib the whole library is in dependencies, and all other functions have no callers. This floods my "Find Items with No Callers" window with useless entries.

FindItemsWithNoCallers.png

 

Suggestion: add option to hide items from dependencies in the "Find Items with No Callers" window (or even hide them by default).

 

Mike_King

A modern and capable DataGrid

Status: New
by Member Mike_King on ‎11-18-2014 12:17 AM

How the ideas exchange has existed for more than one project for anyone and not had a datagrid added already is beyond me.  LabVIEW's table is horible, they need to add a proper grid, similar to flexgrid or other common web grids, that has grid sorting, grouping, sortable columns, drag n drop orders, totals, cell editing, cell binding, cell data types, binding complex objects (clusters), themes (CSS formatting perhaps).

I would find it extremely convenient to have a notification option (or options) to notify the user when the Build Status for a project is complete. 

 

Sometimes when building executables or installers--or both--the compiler can take a while depending on the size of the project.  During this time I don't just stare at the progress bar, but found that even if I left window open in plain view (off to the side or something), it is not obvious when the process is complete (the 'Done' button changes to Enabled and that's about it).

 

Options to notify the user could be any number of things:

  • Beep when complete
  • Bring the dialog to the front (only works if it's not visible already)
  • Flash the window on the taskbar as a notification (maybe)
  • Pop up a modal dialog
  • Some combination of the above
  • Also possible, a checkbox on the Build Status dialog to receive a notification or not
altenbach

Tables should be indicators by default

Status: New
by Knight of NI on ‎11-04-2014 12:02 PM

Looking at all my body of work, I use tables exclusively as indicators. They are well suited to display formatted results in tabular form, but much less suited for user input, because they only allow strings. If we need to enter numbers, there is no input validation (as we have e.g. for numeric controls), so they are pretty useless for that.

 

It is thus a bit confusing that the tables in the palettes currently exist as controls. In fact, the modern, classic and system tables are even labeled "Table Control" (seems redundant!), while "Table" alone would have been sufficient (this has already been corrected for the silver controls :smileyhappy:).

 

It would be much more appropriate if tables are indicators by default. We can always change them to controls in the rare case where this is needed.

 

  1. I suggest that the various table controls in the palettes be changed to indicators.
  2. Their default name should just be "Table".

 

 

 

 

SteenSchmidt

"View As Color Box" option on numerics?

Status: New
by Active Participant SteenSchmidt on ‎10-19-2014 02:00 PM

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

It is always great practice to make your code as readable and scalable as possible, along with good documentation.  One of the things that get overlooked the most, without even realizing, is having coerced inputs to your functions or VI's.  When you have finished developing a program, it goes through a great deal of review to validate all its functionalities.  Coerced inputs can be one of those issues that can come back to haunt you down the road.  I think having an icon on the toolbar and/or a shortcut keystroke to populate a list of all VI's containing coerced inputs would be a great help with identifying all the necessary functions that need to be examined.

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

 

AlexAAuck

Mark Don't Enter During Debug

Status: New
by Member AlexAAuck on ‎11-06-2014 07:07 PM

Hi guys,

 

When debugging, I often find I need to jump over a number of operations before jumping into an operation I'm interested in. It would be nice if we could mark VIs to not be entered (always skipped) when debugging, so that I can just spam the jump into key until I hit the one I want.

P@Anand

Cleanup diagram - Improvements required

Status: New
by Trusted Enthusiast on ‎10-30-2014 11:14 AM

Cleanup diagram is not much used (Personally I allign the diagram myself manually). But if we have few improvements with the tool we can use it atleast in sub vis more often. 

At present the Cleanup diagram tool introduces unncessary wire bends eventhough it can be avoided. So it would be great if this is taken care properly and unncessary wire bends are removed.

 

Manually alligned without wire bends

 

CleanupDiagram-1.PNG

Wire bends are introduced once the Cleanup diagram is done.

 

CleanupDiagram-2.PNG

One of the things that sometimes bugs me when using LabVIEW is that if you have a front panel or block diagram in a small window, many of the menu options and toolbar options are inaccessible without having to resize the window first. You have to have a minimum window size to be able to access all of the toolbar functions.

 

Still don't get it?

 

This is how big I want my SubVI window to be:

2014-10-01_13-24-54.jpg

 

Problems with the above:

  • A lot of the toolbar buttons and menu options are completely inaccessible
  • I'm sure it was for good reason (probably some other icons that appear there), but there's also a load of empty space to the left of the run button which would allow me to fit more of the toolbar on screen

To be able to access the entire toolbar, the windows has to be at least one of the following wide:

2014-10-01_13-25-13.jpg

 

 

Why is this a problem?

 

  • Normally my front panel windows are nicely sized according to the controls and indicators on the front panel (e.g. controls top left, indicators top right, error clusters bottom), for most SubVIs this usually means that the window is thinner than the minimum width to show all of the toolbar options.
  • If you have a fixed size UI panel (e.g. for dialogues) - if you want to align / space objects on the panel you have to make it larger, do the scaling and then resize back to the original size which isn't ideal (possibility for not resizing to the original size correctly)
  • Similar to the above but if you have a UI where you have fit/scale to pane you might want the initial size of the UI to be smaller than the minimum width

Existing workarounds:

 

  • Just before submitting this idea I realised you can shrink the 'search' bar from the toolbar to make it slightly better2014-10-01_13-25-38.jpg
  • Use the OpenG (?) VI for 'fit to largest decoration - this is OK for some UIs but not really suitable for the SubVI case above

Proposed solution:

Please make it so that the menu and toolbar are accessible regardless of window size. One solution would be to have a button that allows you to 'scroll' the toolbar or have a pop-up dialogue that shows the missing toolbar buttons as per the image below.

 

MS Paint skills (icon lifted from Chrome's bookmarks bar):

2014-10-01_13-24-54_fixed.jpg

 

As an aside, MS Word manages it fairly well (even though it isn't that readable), and it has a LOT of toolbar buttons:

2014-10-01_13-44-07.jpg

 

Please consider my idea (or Kudos it) for future versions of LabVIEW - it will improve usability of the IDE.

SFK

allow blocking of NaN in numeric data entry

Status: New
by Active Participant SFK on ‎10-24-2014 11:12 AM

Recently, I discovered an annoying "feature" of LabVIEW: if you limit the data entry of a floating point numeric to a maximum value with coercion enabled, entering NaN to that numeric will be coerced to the maximum that you set in the data entry dialog.

 

I already reported that as an unexpected behaviour, but after some more thinking, I dare to go even further and propse:

 

allow the blocking of NaN in floating point numeric data entry

 

idea_discard_nan_data_entry.png

 

The logic needed should not be much more than a finger exercise, as string controls already allay to discard CR/LF with the "limit to single line" property.

 

Best regards,

Sebastian

ouadji

LVPROJ : Rename a folder

Status: New
by Trusted Enthusiast on ‎09-22-2014 02:54 AM

                             

                              lvproj : be able to rename a folder

 

SR2.png

 

             SR3.png

Norbert_B

Probe terminal

Status: New
by Trusted Enthusiast on ‎10-24-2014 06:49 AM

During implementation of code, the algorithm and its implementation has to be tested and debugged in most cases many times. For debugging, probes are a very useful tool. But probes can only be created on existing wires.

If, for any reason, the developer wants to probe values which are not on a wire already (e.g. iterator of a loop), he has to create an indicator (or tunnel) in order to have a wire. Once the debugging is done, the terminal/tunnel and the wire should be deleted.

 

I find it would be much easier, if i could right-click the data output and select Create >> Debug Terminal. This terminal is part of the code, but once i close the probe, the items created by this option (terminal and wire with probe on it) are removed automatically.

 

Norbert

 

PS: I know that there was a suggestion specifically for the iterator of a loop. I understand the reason why it was declined, but i find that using VI Scripting, the above mentioned functionality could be provided. As i WANT to have the information of that wire during debugging, i require that terminal/wire in any case. Using some automated tool would ease the debugging process with the hope to decrease time required to identify the software anomaly.

Latest LabVIEW Idea Exchange Blog Posts
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
User Kudos Count
95
74
39
26
22
Idea Statuses