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

Path Control Disable Text Entry

Status: New
by Trusted Enthusiast on ‎07-07-2015 12:12 PM

If I have a path control on my front panel for the user to interact with, I will always show the browse button.  This button makes selecting a path easy from a user perspective, and from a developer I know that the path they selected has some level of validity.  So for instance I know that the path they selected must exist and be a valid path otherwise Windows won't let them select it, and the value change won't be triggered for the control.

 

But the user can manually type in text into the path control, and when focus is taken off the value change event will take place.  The problem with this is the path they entered might not be valid, or may contain characters my platform doesn't support.

 

I doubt a user will manually type in text in the control often, they will use it as an indicator showing the path they selected using the browse button, but on the off chance that they type somthing and it isn't valid, my code might crap out throwing errors.

 

I can add code to check for a valid path, and I can add code to check for illegal characters in the path, but I'd have to do this for every path control on every UI the user sees.  I could also write an XControl for this with a decent amount of work and hopefully meet my needs, but it would be nice if this were a native feature.

 

So what I'm suggesting is that the path control have an option, possibly in the browse options dialog, which makes the interaction with the control, only available by using the Browse button.  This would ensure that any value change event will be from the user picking a valid path with the browse button.

 

 

Problem:

I faced to delete multiple elements form the array which is having 20 steps.

 

solution:

if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.

 

 

Array element.png

 

 

Allow project explorer window to be pinned

Status: New
by Active Participant ToeCutter on ‎06-29-2015 05:58 AM

I have a large library of general purpose functions and I do a lot of OOP in LabVIEW, and as a result my preferred workflow involves dragging a lot of functions from the project explorer window onto the block diagram. This workflow is slowed down, however by the fact that the project explorer window is regularly hidden by other windows when I click on them.

 

What I would like to see is something like most development IDEs have, e.g. Visual Studio, where I can have the project explorer always visible in a fixed position on the screen. I suggest this would be an option, so would not affect those who like things the way they currently are.

I just had a case today where I had an existing wire (An array of configuration parameters) and I selected the wire and then tried "Create Sub-VI" on it.  Nothing happened.

 

Perhaps it would be simply consistent behaviour if we then allowed creation of a simple VI with Wire Datatype in and out with input terminal connected to output terminal.

Should be able to specify tolerance instead of just upper and lower limits. This de clutters the application block diagram when you are checking for a value within certain limits.

 

 . Upper limit becomes : x+ tolerance, Lower Limite becomes : x - tolerance when using tolerance instance of the polymorphic vi.

 

For even higher level functionality , specify units of tolerance : absolute, percent(1e-2), parts per million (1e-6), parts per billion (1e-9)

Say I paste a function down inside some structure, say a case structure. I wire from the input of the function back to the left hand border of the structure, which creates a tunnel with a 'broken' (dashed) wire to the function.

 

I would like to be able to right click on the tunnel and hit 'create control' and have it work. Although the wire is dashed, there's no ambiguity about the correct control type as it needs to be the same as the function input.

View and modify splitter hierarchy

Status: New
by Active Participant dsavir on ‎06-17-2015 03:01 AM

I use Splitter extensively to create resizable GUIs. However, if I create my resizable GUI and then my customer asks me to add parameters in a new pane on the left, I can't add to an existing GUI a splitter in the top of the hierarchy, i.e. a new vertical splitter that all the existing splitters will be on the right of the splitter and a new empty pane on the left. Any splitter I add will be added to the bottom of the existing hierarchy, and there is no way to change this. So to do this I basically need to rebuild the GUI again from scratch.

 

Another example, if this is my GUI:

scope.PNG

I can't add a status bar now, as any horizontal splitter I add will be inside an existing pane, and this can't be modified. However, if this idea were implemented, I could View splitter hierarchy and create a new horizontal splitter at the top of the hierarchy so that I would have my status bar without rewriting the whole thing.

 

 

Thanks,

Danielle

 

Picture says it all.

 

Concatenate with an option of 'concatenate to new line'

 

 


I am not allergic to Kudos, in fact I love Kudos.

 Make your LabVIEW experience more CONVENIENT.


When first launching the Quick Drop tool it can take a while. This isn't a problem in itself, but the fact that you can cancel the loading or continue working in the background is. This is especially annoying if you launch it by mistake.

 

Not a major thing, just something that could be improved.

 

Quick Drop idea.PNG

NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.

 

I suggest that NI start shipping USB keys instead. USB has several advantages:

 

  • USBs are smaller
  • USBs are more usable on devices without DVD player
  • Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
  • USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.

 

Ship developer suite on NI USB keys

If you have made a custom run-time shortcut menu and saved it as part of the control (always necessary for applications due to this issue), it is currently way too easy to lose that menu. If you replace the control, even though it is with the same type of control, the menu is silently lost. So if you have made right-click shortcut functionality, the user will no longer be able to call that funcitonality.

 

lostmenu.JPG

 

Possible solutions:

 

warning.png

 

a. As a minimum you should be warned that the control you are about to replace has an embedded shortcut menu.

b. The warning could give you the option to copy the menu to the new control (OK set as default), or

c. The new control could automatically inherit the original's shortcut menu

d. -Alternatively only if of the exact same type (if you for example replace a modern styled listbox with a system style listbox).

I would prefer alternative b, as it would draw the developer's attention to the possible issue of the embedded menu (perhaps it is *not* wanted anymore, perhaps it is...), but make it quick and easy to choose to keep the menu (most frequent I would guess).


Project Explorer: Hovering over a Virtual Folder during Drag & Drop should open that folder

Status: New
by Trusted Enthusiast ‎06-05-2015 12:50 PM - edited ‎06-05-2015 12:54 PM

In the project explorer, dragging an item into a folder opens that folder AFTER the drop. This is annoying. But I digress...

In fact, what would be useful is to have the behavior of the two file explorers I am familiar with (Windows and Mac OS), that is:

 

- if an object is drop onto a folder icon, the folder does not open (see link above)

- if the object is held for a while over the folder icon, the folder opens

 

This is particularly helpful if the project explorer has a hierarchical structure of Virtual Folders:

 

Screen Shot 2015-06-05 at 10.44.15.png

If I drag Untitled 1.vi over the Action folder and hold it here for ever, nothing happens, and in particular, I can't access any of the the subfolders.

After dropping it, I get this:

 

Screen Shot 2015-06-05 at 10.44.40.png

 

Now the top folder is open, but the VI is nowhere where I want it to be and I need to repeat the drag & drop action.

 

This example doesn't do justice to the real issue which is that for large lists of VIs and folders in a project, this becomes a real problem, as VI and target folders (after everything is opened to provide a clear path from original to target destination) may end up separated by large amount of space in the project explorer and you now have to use the temperamental "Drag the object over the 1-pixel wide location at the top of the project explorer to trigger scrolling" feature in order to slowly bring the object to its remote destination.

If you need to wire cross other wires it would be nice just for the optic to have the error wire always in the background of the cross. Now the wire which is connected first is in the background and all other overlay it.

Close Project

Status: New
by Trusted Enthusiast on ‎03-21-2015 02:03 PM

 

 

  It would be very usefull to know which VIs are still running.

   aaaa.png

VI Scoped Type Def

Status: New
by Member --thatguy on ‎06-24-2015 11:16 AM

When creating a state machine it's often handy to use an enum that lists all your states.  

You then take that enum and make it a type def so that if/when you update the enum (to add or remove a state) throughout the states, all instances of the enum get updated.  

 

But the thing is, now this potentially simple state machine VI requires this secondary type def file.  No other VIs would need access to this type def so making it a seperate file just shouldn't be necessary.

 

Vi Scoped.jpgVi Scoped_2.jpg

 

transparency for plots in graphs and charts

Status: New
by Trusted Enthusiast ‎06-23-2015 04:49 AM - edited ‎06-23-2015 04:51 AM

In addition or extention  to this idea

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Graphs-and-Charts-with-semi-transparent-fill-option/id...

 

I would like to have a transparency control/property in the colour selection for plots in graphs and charts.

 

Quick drop catch key presses while loading

Status: New
by Member Richard_Ha on ‎06-24-2015 06:23 AM

Have the quickdrop catch the keyboard shorcut keypresses while it is loading the list.

 

At the moment my VIs keep trying to run becuase I've pressed Ctrl+R quicker that quickdrop has loaded the list in.

Control reference Size improvement for space saving

Status: New
by Member PBP on ‎05-26-2015 10:27 PM

HI This idea may be addition to THIS.

Untitled.jpg

PBP 

Formula node forbid to run VI when undefined variable is used

Status: New
by Active Participant Ytochigi ‎06-25-2015 07:12 PM - edited ‎06-25-2015 07:13 PM

On all LabVIEW version, we can use Formula node to evaluate mathematical formulas.
We can define input and output variable freely and calculate using some variety of formula.
But when we use undefined variable as output, can execute VIs with no errors.
We think it is a problem because when programmer makes a typo, they cannot notice the mistake.

 

When undefined variable is used as output variable, LabVIEW should forbid to run VI.

 

a.PNG

The various instances of the polymoprhic XML Close VI all have standard error in functionality.  In other words, they run normally only if no error occurred before they run.  That can lead to references not getting closed if errors occur in sections of code that execute earlier.

 

Instead, the XML Close VI instances should run normally even if an error occurred before they run.  When calling the XML Close VI, it is a nuisance to have to clear the error passed in to it and then merge the previous error with the error output from the VI.

 

In addition, most of the other Close functions and VIs in LabVIEW run normally even if an error occurred before they run (Close File, UDP Close, VISA Close, Close Reference, DataSocket Close, etc.).

 

There may be other VIs and functions that have the same behavior as the current XML Close VI and they should be changed as well.  Examples include TDMS Close, Close Zip File VI, etc.

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
55
47
46
45
36
Idea Statuses