Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.
To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.
A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:
In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.
When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:
Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:
To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):
The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.
There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂
There seem to me to be a couple of choke points in right-click access to VIs and functions. One is that I frequently need to use the same VI's repeatedly. Another is that the quite useful "insert" and "replace" context items only offer a few first-tier options: one or two related palettes, or all palettes. Try to insert a few datalog functions for example, and you have to navigate down 6 levels for each. It's even worse if you have to use "select a VI..." and browse to it. For the worst cases, insert and replace lose their advantage over copy-paste or quick drop.
I propose a dynamically generated palette consisting of the last several VIs and functions (even controls) that have been dropped. This is analogous to recent-commands-list functionalities common in CAD packages.
- As a member of the functions palette, the items in it are at or above the level they are in their normal place in the hierarchy.
- Since it's a palette you could pin it and it would be handy for dropping the same node on two different block diagrams
I use the conditional disable structure in my projects to turn debug options on and off.
At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.
You can get around this by automating you build but an option in the build specifications would simplify this.
It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.
I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:
It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):
When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.
Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.
After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.
Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.
Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project. I never use the default icon provided by NI. -- N-E-V-E-R -- That's a personal choice.
So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless. Let's see how many users of LabVIEW also find the default icon useless.... (Kudos would be a way to take a poll).
A nice feature would be to allow the developer to create her / her own default icon. The default icon is probably somewhere in the ini file (I have not checked). One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.
In my case, when creating a new VI, it ends up with a icon like this:
I would be happy to have a default icon that looks like this:
The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.
It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).
The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.
A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.
See attached pic for an mock up.
There are probably lots of menus that could benefit from something like this.
Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.
The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.
I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.
Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.
One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.
1. allows you to know the exact size in pixels that the front panel will get at runtime, while the manual resizing of the FP occurs. This feature should take in account VI's Windows Appearance options (Window has title bar, Show toolbar when running, ... etc). It helps you to set the FP size for the (different) screen on wich the program has to be run.
2. this feature can help you to set the BD size for the smaller screen on wich you know you'll have to edit the program.
Up to now you can only set a minimum FP size, and use it as a sort of "pixel size reference". However this is the internal net size of the panel, toolbars and title bar excluded, and the final setting is a bit tricky. You can also programmatically change the FP size, but this is of little use, if you don't want to risk that some control disappear out of the panel boundary.
The second benefit is only for those of you that use LV on different PC (Lab and laptop, for instance) like me... and, like me, hate having to scroll the BD for editing it :-). Usually I set the BD size to the maximum possible dimensions of the smallest screen I use.