LabVIEW Idea Exchange

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

When searching for text in LV 2014 (from 2015 DS1), it appears that the Window Title text isn't picked up by the search. 

 

To verify this, I created a new VI, and modified only the Window Title (File -> VI Properties -> Window Appearance -> Window Title, Click OK, Save VI).  Then press Ctrl + F, Select Text, type in a word in the Window Title.  Not found .

 

We should be able to search on any text saved anywhere in the VI (in cluding VI properties like Window Title).  Please expand the find capability to search Window Title and any other relevant fields.

Hello,

 

Could You allow to resize Rearrange Cases window? 

 

[Note from admin: dead hotlinked image removed. User asked to provide new image.]

 

By default it fits only 8 cases and it is hard to move and work with it when we have to rearrange 30 or more...

Other idea is to select many cases by holding Shift

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)

Sometimes I have several parallel array wires and I want to probe one of them with a graph probe. During debugging, I notice that I actually want to probe one of the other wires instead.

 

Current procedure:

Create an new probe on the other wire. If we do that many times, we will have so many probes as to make it difficult to keep track of them all.

-or-

Create a new probe on the other wire and delete the old probe. Several steps.

 

Wouldn't it be nice if we could Control-click on a probe number on the diagram, get the switcheroo cursor, and then click on a different wire of the same type to move the probe over. It would work very similar to how we currently are able to swap terminals on the connector.

 

Summary: Allow switcheroo on probes 😄

Retina displays on macs are really nice to work with, the details quality is a real plus, it would be nice if LabVIEW could take advantage of that, for now LabVIEW look really blurry & ugly on a retina display.

 

See the difference between LabVIEW and GitHub :

LV & git - no zoom

 

Zoom on LV :

zoom on LV

 

Zoom on GitHub :

zoom on github

SR4.png

 

for the code around the sequence, an growth of the code like "add frame"

 

 

 

Currently, any VIs including .NET code are shown as broken in Labview for OSX.

This is particularly annoying for people working in a cross-platform environment, specially considering that the Mono framework covers a lot of Microsoft's .NET implementation with the added bonus that it works in Linux, Windows and OSX.

 

Please allow users to choose which .NET implementation to use.

Hi,

 

for a complete validation of a software, it is mandatory to perform tests. When testing, we differ between two major tasks:

- static code analysis

- dynamic code analysis

 

For static code analysis, we got the VI Analyzer toolkit. It automates the task of looking into the sources (front panel and block diagram) and compare the current layout against recommended layout (style guide). Additionally, it detects known sources of issues for lack in performance or even crashes and misbehavior during runtime.

 

So it makes perfect sense, to define requirements that static code analysis has to be performed before proceeding to dynamic (runtime) code analysis.

Yet, VI Analyzer tasks have no option for creating such a link as a field "comment" or "description" is missing for the configuration!

 

I suggest to add such a field in the cfg-file level (exported VI Analyzer configuration) where we can add strings like [Covers: <req_ID>] as we are used to in LV code.

 

Norbert

It would be nice to be able to resize or move a free label while editing it. This idea revolves around a couple of situations that can occur when typing up long free labels.

 

Situation 1

If I type up a long free label inside of a structure, then I can't resize or move the free label while I'm typing in it. If it becomes too long and extends outside of the structure I'm typing in (loop, event, or case structure), then it automatically expands the structure no matter what I do next.

 

As soon as I click out of this free label or try to resize it, it will resize the While loop. Usually, this isn't my intention. I usually want to shorten the width and increase the height (to make it multiple lines), or move it somewhere else. Currently I have to finish typing, resize or move the free label, and then manually resize the structure to its previous size. If instead I can resize or move the free label as I type, then I don't have to manually resize the structure to its original size; I can just fit the free label where I need to in the first place.

 

This same behavior occurs if I try to move the free label while typing in it; the structure resizes, even though I'm moving the label outside of it or somewhere else.

 

idea exchange - resize free label 01.png

Then as soon as I finish typing...

idea exchange - resize free label 02.png

 

Situation 2

If I type up a long free label and the single line runs to the right of the block diagram, then I can't see what I am typing.

 

idea exchange - resize free label 03.png

 

At this point, it would be nice to resize or move the free label. Instead, I have to resize my block diagram window, or click out of typing, move the free label, and double-click to continue typing.

 

 


Thanks for listening!

Yes, I know I'm probably the only person in the world that enables the warnings view in the Error List, but I'd like to be able to selectively ignore certain warnings. For example:

 

warning.jpg

 

The FP control that I'm getting a warning about is handled in an event structure, so there's no need for me to wire to it in this context. I'd like to be able to right click on that warning and select "ignore" (just like I can for the TestStand sequence analyzer - which is awesome FWIW 🙂 ). Doing so could remove if from the list, or gray it out and push it to the bottom of the list (maybe in a new section called "Ignored Warnings"). I would also want a method to restore all previously ignored warnings.

Current "Format Into String" code may look like:

 

                             before.png

 

This can be very confusing.

 

Suggested "Format Into String By Name" Code may look like:

 

                       after.png

 

In order to define the input names, a new filed called "Inputs Name" can be added to the "Edit Format String" dialog (available in the right click menu).

 

Amir.

In my experience using and developing software it is typical save behavior to simply exit the dialog when a user clicks Cancel to a save operation.  This is reasonable if, when the file selection dialog is open, the user does not click anything (i.e. there is nothing in the file name field) and just clicks Cancel.  However, when the user has selected an existing file from the directory or there is a default file name in the file name field, I like to warn the user that the file was not saved when Cancel was clicked.

 

When invoking the Export Image method, if Always Overwrite is False, it will prompt the user if they are about to overwrite a file with dialog box that has an Ok and Cancel button.  This is great however there is no way to capture what the user clicked.

 

NIExportImageInvokeNode.PNGNIExportImageInvokeAreYouSure.png

 

 

It would seem like good form to have a Canceled or Ok output just as in File Dialog express VI. 

NIExportImageInvokeNode+Cancelled.png

This idea is a general request for NI to improve accessibility features for physically disabled users.  The background for the request is in this post.  In general the problem stems from LV's overreliance on precision mouse control.  I don't want to focus on a specific feature as I think the best solution will be a combination of features, possibly including the following:

 

* Better support for hotkey customizations.

* Ability to select and manipulate FP and BD elements with the keyboard.

* Block diagram zoom so users can zoom in when they need to target a small element, like a terminal or loop resize handle, or zoom out to navigate a large block diagram.

 

Here's an example of how I envision these features might be used to wire two nodes together:

1. While the keyboard is in "selection mode" I use the arrow keys to change which node is selected.  (i.e. Has the marching ants.) 

2. When I get to a sub vi with a terminal that needs to be connected I hit 'w' to enter "wiring mode."  This allows me to use the arrow keys to select the specific terminal I'm going to connect.  When that terminal is highlighted, I hit the spacebar to tag that terminal and go to the next step.

3. Using the same process as step 1, I highlight the node with the terminal I want to connect to and hit the spacebar, activating the ability to select a terminal.

4. I select the terminal using the arrow keys and hit the spacebar, and LV inserts the wire connecting the two terminals.

 

Again, this idea isn't requesting those features specifically (though they are all features I'd like to see) or claiming the workflow I described is the best solution.  They are just examples of one way to help disabled users.  The important thing is having a solution that works.

More of a complaint than an idea. The Silver and system controls schemes looks really good but they are far too incomplete to use it in a GUI. I can't tell how many times I've started a UI with one style of controls then abandoned it because the mix and match look looks like hell. How much trouble would it be to create a new control (or create existing controls) in every style? It would certainly make NI/LabVIEW *look* better. And we should not have to rely on interest groups, either.

For some reason, FXP representation is not allowed for most controls and indicators (sliders, dials, gauges, etc.). Only plain numerics are allowed.

 

This seems like an arbitrary limitation. Similar to their use with integers, they should simply snap to the nearest valid value.

 

 

 

IDEA: Allow FXP for most controls!

When deprecating a VI it is important to alert the programmer. Most of the time I'll color the icon for the VI a different color than others in the same library/class as a hint, "Hey, I'm different, you had better look at the documentation if you plan on using me!".

 

However when dealing with class properties, you don't see the icon so this hint can easily be missed. Internally LabVIEW will color code property or invoke nodes if they call "super-secret" or deprecated interfaces. It would be ideal if this functionality was exposed such that we could take advantage of it in classes:

 

Depreciated.png

 

This idea stemmed from a discussion over at lavag.

There are times where I need to refactor an application's code and I use "Find" from the project explorer window to locate caller's of a specific VI.  Once the list is populated, I would like to visit each of the "Callers" in the list and review the code.  However, when I pick an item from the list, the Find result dialog box is dismissed.  I need to re-do the Find and keep track of the VI's I have looked at manually.  This feature would be more useful if the Find results remained visible and I could interract with it like I do with the "Error List" dialog, or the "Search Results" dialog box. 

When debugging you often want to find all the locations that a property node or variable is being written or being read. It seems it would be a simple matter of adding a column indicating if the searched item is being written or read at that location. 

When you have a cluster constant and you want to make the elements the same size, it would be nice if you just selected them and set them to the max or the min width.

Undeterred by the tepid response to the following ideas:

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Integrated-snippet-manager-for-block-diagram-code/idi-p/1230663

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-new-palette-to-store-user-developed-vi-snippets/idi-p/966925

 

let me suggest an alternative:  When choosing 'Select VI...' from the palette or Right-click menu I would like to be able to select a Snippet as well.  I would prefer that PNG files would be shown by default, but I do not have a problem with switching to 'All files' or having Snippets (*.png) be the next option in the file type pull-down.  PNG files without snippets can throw the usual error.

 

Unlike dragging snippets, this method *should* allow the code to be placed on the cursor for more controllable placement unlike the current drop and look-out below method.