LabVIEW Idea Exchange

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

Many controls allow you to make scrollbars visible. When a user clicks anywhere within the control, including on the scrollbar, this counts as a Mouse Down. It would be nice if the Mouse Down event would indicate whether the click was on the scrollbar or on the actual clickable area of the control, so you could do different actions based on which it was. Of course, you can usually do manually by checking boundaries of the control against the coordinates of the click, but it seems like a common thing so it would be easier if the check was built in.

Scrollbar Idea.png

It's very frustrating to have your floating probe windows disappear when a LV modal window is presented. Frame 1 below shows probes set up, and Frame 2 shows how they disappear when a modal window appears:

 

ModalWindowsEatProbes.png

 

Some of the most annoying modals that pop up while troubleshooting include: 

  1. "Save changes before closing?"
  2. "Waiting for Real Time Target to respond"
  3. Error windows

#2 and #3 modals windows recently made it impossible to use probes since I was trying to diagnose a problem that constantly would throw those modal windows.

 

Proposed Solution: Don't ever hide probe windows, regardless of what pops up.

It would be great to be able to have multiple "Search Results" windows open at the same time. 

 

A few typical use cases:

  • Some searches can take a LONG time, especially where dynamic dispatch is involved. It is always painful to have to close a big search just to do a small one.
  • Sometimes I need to search through instances of two or more distinct items for comparison purposes. 
  • Searching is a handy way to navigate. Leaving a search window open is like keeping a bookmark to a useful part of the code.

search.png

 

The only issue I see is that keyboard shortcuts (e.g. "Ctrl + G") would need to be restricted to only one of the windows. It seems reasonable that keyboard navigation could simply apply to the topmost search results window.

Most languages I have worked in have had a library for common data containers (Tree, Linked List, Stack/Queue, Hash Table, Map, Etc.). I understand that these data structures can be made by using an array and storing array indexes.

 

Lets face it, it stinks to have to write your own data container evry time you can't force a queue to do something it was clearly not meant to do be able to do, like be a stack.

 

The advent of classes in labeled was great & I have spent plenty of time creating data structures classes, but the problem is that without templates, or the ability to have more than one kind of dynamic dispatch terminal in a VI, you end up having to write a wrapper to box & unbox your data.

 

The other problem that I have found is that generally all data must be put into a array for storage. This makes inserting and deleting items from trees and link lists tricky.

 

I think a set of native data containers along with the operators/methods to manipulate them should be added to labview. It would be nice if upon creation there was a polymorphic terminal that would allow you to wire up any basic primitive type (numeric, double, boolean, string, cluster, references, etc.) as well as classes (not just the LV object, but a template like approach) and variants.

One piece of code that I am tired of looking at is calculating start and length from start and stop indices for Array Subset.  I find that more often than not, I have start and stop indices as opposed to start and length.  I would like an option on the existing node to use start/stop, or even a new node if necessary. 

 

NewSubset.png

 

(If a new node is created, expandability would be nice)

The Class Hierarchy window is a great tool to see the relationships between classes. It would be even better if you could use it to change those relationships.

 

I imagine something identical to the way we program with G: connecting wires and moving around icons. A user should be able to drag a class icon around in this window and wire relationships as they see fit.

 

21133i7D399BB1CC32A52F

 

1. Notice an additional button in the Hierarchy window. This is what's used to draw the relationships.

2. By moving an item out of the row (or column if using the "Horizontal Layout") that it's in, the relationship wire disconnects.

3. Using the wiring tool, a user can reconnect the relationship at a different level. Now the red one I've moved is a grandchild of Green.

4. If the user tries to make an invalid relationship (multiple parents, children higher than parent, etc.), then the wire shows broken. The Class Hierarchy window cannot be closed until it's fixed.

 

 

Discuss! I'd love some feedback on this idea. Good? Bad? Better method available?

 

Support project based vi-analyzer configuration which containing target specific information (important e.g. to correctly analyze FPGA VIs) to be executed with the vi-analyzer api to be integrated into CI process. 

A big project can take more than 10 minutes to load, especially on an older computer.  If subVIs are missing, the Ignore Item and Ignore All buttons become available when the first VI is missing.  This can happen anytime during the loading and the process stops until the browse box is canceled and then the Ignore All button is pressed. 

 

It would be better if the Ignore All button was always available where it can be clicked at the beginning to insure the project is loaded in the expected time.

Ignore All.png

Currently there is no way to delete multiple elements in an array, that are not in sequence.

This way elements 2,4,7 would be deleted in just one function.

 

Delete from Array.png

 

It is cleaner code and in big arrays can enhange performance (at least i think)

If you change the comparison function "Is Path and Not Empty.vi" to a malleable VI, then it will be able to accept arrays of paths.

While helping in the forums, we regularly run into VI's saved under an older LabVIEW version, modify it and post it back, usually saved in the latest LV version. Soon after the original poster complains, asking for a converted copy.

 

Years ago, I even proposed a small starware utility (Get VI version) that returned the LV version any vi was saved in. Unfortunately, it stopped working with LV 8 (and didn't recover since... ;)).

 

I found several proposals for displaying the version number (for instance here and here), but they are related to the application version and not to the vi version. None corresponds to this very basic idea : as long as a vi has been saved in a version different from the one in use, display it as unsaved (using the usual star), with the original version number attached. Something like this :

 

19239i840BEC563A1BADB9

 

Alternatively, when saving the vi, the programmer could be proposed to choose the former LV version.

 

 

 

PROBLEM:  There are often times when I decide I would like to include some code that is just outside of a structure.  Currently in order to get it into the structure I have two options:

 

  1. Grow the structure, move the code inside, reattach all the wires, rearrange code so that the spacing is correct again.
  2. Delete the structure and readd it.  (This option is not valid for sequence structures where I'just want to move code from one frame to the next.)

SOLUTION:  Allow a control (or shift) when resizing a structure that causes the structure to capture the code rather than move it.  This should not break any wires.  In essence, it would be like redropping the structure..  Note this could also work in reverse.  If you size a control smaller, it would exclude anything outside the new boundaries of the structure.

 

Tunnels for FOR loops are autoindexing by default. Sometimes this is not the correct option for very obvious reasons and we get a broken wire.

 

The diagram editor should be smart enough to try the "other" option (e.g. no autoidexing) if a broken wire results. If the other option succeeds without a broken wire, it should be used automatically. Maybe the tunnel could "glow" for a few seconds with a small option box (similar to e.g. when pasting into word: keep formatting, text only, etc) that would disappear after a while where we can click and overwrite the automatic handling.

 

The image shows two wires that would be a candidates for autocorrection of the indexing option. In both cases, LabVIEW should disable indexing automatically to avoid broken wires.

 

If both options result in a broken wire, nothing should happen, as before.

 

(Similarly for while loops. e.g. if I wire a scalar across the boundary to an array indicator, it should autoindex.)

 

It would be absolutely helpfull if Graphs would have Annotation font properties like Labels  have on generic control.

 

 

New properties for Annotation in annotation List that could allow to change "test" text fonts attribute.

Graph Annotation Font Properties

 

 

Graph Results

Hi,

 

Often you see in code one large text box for comments and labels on each section of code for which the comment applies.

 

How about a small speach bubble type icon which can be placed on the block diagram, which when clicked/hovered on will pop up comments either in its own window or in the context help window.  This could be linked into the new requirements tracking tools as well.

 

Craig

When you mass compiled, all VIs in the directory tree get recompiled. When you hold CTRL and SHIFT and click the run button on a VI, it forces a recompile of all VIs in the call chain. 

 

However, when you CTRL-SHIFT-Run, all you SEE is a busy mouse; it would be really nice if you could get a popup windows (the same as when you mass compile) showing what's going on, and giving options to cancel... it would also be nice to be able to specify a log file and how many VIs to cache, same as with mass compile...

 

It could be the same popup with a different title...

 

 

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number.  For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later.  Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions.  However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

  • Changing VI connector panes
  • Renaming or moving VIs on disk
  • Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

 

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs.  Consider the case where I make the following changes to a VI from my toolkit:

 

 

Version 1.0

Version 2.0

VI Path

 

<userlib>\mytoolkit\CompRes.vi

<vilib>\mytoolkit\Compute Result.vi

Owning Library

 

none

Mytoolkit.lvlib

Connector Pane

 pane1.png  pane2.png

 

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI.  This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

 

                             below, here is the "old" File-Dialog

 

         toto3.png

 

                                       But NI advises this :

 

                              toto1.png

 

 the problem is that this "new" File-Dialog isn't aligned like the "old" one

 

      toto2.png

 

                Please ... align this "new" File-Dialog-Express-VI"

 

                                                  (thank you)   Smiley Happy

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

After deleting items I don't want in the project, or loading plugins in a  plugin architecture, I want to remove them from the LabVIEW memory. This is not possible now, as they go into Dependencies->Items in Memory.

Items in memory.PNG

The only way to do this now is to close and open the project, which over a large Plug-in architecture project is a real pain. 

Ideally, I would like to right click the folder and choose "remove from memory". However, any option that allows this would be good.

 

Thank you!

Danielle