LabVIEW Idea Exchange

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

I've long wished Labview had native support for Interfaces.  Recently I ran across an article describing Traits as a better alternative to Interfaces, Mixins, Multiple Inheritance, etc.  Traits are (as near as I can tell) similar to Interfaces with the main difference being Traits can define a method implementation while Interfaces can only define a signature.

 

I'd like to see Traits implemented in G instead of Interfaces.

 

(Cross posted to LAVA.)

 

 

When I don't know a VI too well or am not really sure what I am looking for it would be nice to have context help display information for the items in the Quick Drop window.  For example I was looking for a noise VI and wanted to see the inputs and outputs of the VI's listed in the quick drop, but you first must choose a VI to get this information. 

 

 

Properties of a numeric control or indicator is using a scroll box to set the Type (see dump below). A closer look reveals that this dialog is poorly laid out - there is plenty of room to display all the contained information without having to resort to a scoll box. This issue appears to be specific to LV2012. In LV2011sp1 it is nicely done.

 

This is a very simple and low risk thing to correct and improves usability at virtually no cost. It may appear as an insignificant thing, but a top notch tool like LabVIEW should take care of all such small details.

 

Here is a dump of before and after the improvements...

Display type scroll box.png

I often need to interpret JSON formated Strings.

Until now I use regular expressions.

 

A JSON-Parser (like the LabVIEW-XML-Parser) should simplify the expense for me drastically.

In addition to displaying the names of all palette items, Quick Drop will also display the names of all VIs, classes, typedefs, etc., that are present in all currently-open projects. It has been suggested to me that we should provide a configuration option in Quick Drop to only display project items from the currently "active" project, to avoid potential cross-linking issues that can stem from accidentally dropping an object from one project into a VI that is open under another project.

Currently the event structure is not part of the base development system. It is such a useful and necessary structure that it should be included in all versions of LabVIEW.

On downloading a file from internet and if the file already exists (file with the same name), it automatically appends an auto-incrementing number to the file name, wouldn't be it nice to have the similar feature (may be optional) with Open/Create/Replace File Function.

 

Append with auto incrementing number in the file name

 

 

Consider the scenario, you've enabled this option ('append number if file already exists' as shown in above figure) while using Open/Create/Replace File Function and operation input is 'create' and name of the file is MyFile.txt, which already exists then this fuction should create a new file with name MyFile (1).txt (or may be MyFile (2).txt if MyFile (1).txt also exists and so on).

After 2011 we have the option to ignore all the missing vi's which are missing. But after loading the project if a vi is loaded and if it has a missing vi then there is no way to check from where it has to be loaded (Expected path of the missing vi). So it would be a good option to check the Expected path of the missing vi after loading its caller (May be in the properties of the missing vi).

[Cross-posted here on the JKI blog]

 

One LabVIEW feature that (if it existed) would make a big difference for VIPM users is the ability to refresh the menus (e.g., the FileTools, and Help menus) programmatically after installing packages that add menu-launch VIs.  Maybe we could do this if LabVIEW added a new VI server method called Application:Refresh Menus.

Note: this would be similar to how we can refresh the palette menus programmatically by invoking theApplication:Refresh Palettes method (shown below).


refresh-palettes

 

I bring this up, because one feature that I’d love to see added to VIPM (some day) is an easier way to build menu-launch tools into VI Packages, and I’m sure more people would be asking us why their add-on doesn’t show up in LabVIEW after it’s installed.

Hopefully, we can help NI get this feature onto the LabVIEW roadmap by convincing them that it’s worthwhile.

I would want the option to create anchors in LabVIEW code, these anchors could be used to

  • navigate inside LabVIEW code between different parts of the code
  • Easy jump to specific section
  • Connect different states as a documentation tool

These anchors wouldn't change the execution of the code, they are only meant for documentation and should be named. For starters they would only be global in their own VI block diagram, but that could be expanded.

In a document describing the code, you could refer to a specific section (loop, case structure), or you could create a note in the code 'this code starts the following case structure' etc.

 

Ton

Every time I need a variant constant, I have to:

1) Pick any function from the Cluster, Class & Variant functions palette>>Variant

2) Place it in block diagram and right click>>create>>constant

3) Delete function.

 

I believe the variant constant should be in that palette.

 

I did a search in the functions palette for "variant constant" and it is not there.

 

Please add the variant constant to the Cluster, Class & Variant>>Variant function palette 🙂

 

Thanks,

Fab 

The provided model templates (fitting, optimization, etc. listed here) have the ancient icon style where the text is actually merged into the single layer of the icon.

 

Since in the typical scenario the text will be immediately changed to reflect the actual customized model name, it would be reasonable if these icons would have the current text editable in the icon editor instead. Currently, we need to erase the icon background before we can start typing or we get a mess.

 

For example, in the nonlinear fit model, the text "curve|fit|model" should be in the text tab, and not contained in the icon background (see image).

 

Suggestion: the model template icons should be blank and the current text should be pre-filled, but editable on the text tab of the icon editor.

 

 

The LabVIEW compiler currently appears to use one core of a multi-core processor.  It would be nice if it fully utilized multiple cores to speed building of large projects.

LVOOP, "Choose Implementation" dialog box:

I'd love if the items appeared in alphabetical order.

At the moment it's pretty hard to find the desired implementation when you have something around 50 child classes.

 

implementations.png

According to my understanding and the following discussion:

http://forums.ni.com/t5/LabVIEW/Why-exactly-can-t-I-inline-this/td-p/3126562

certain types of Property nodes and Invoke nodes should be inlineable without any great problems.

 

I would suggest that the LabVIEW compiler get's a bit smarter about this aspect of limiting the ability to inline code.  If there's no technical limitation regarding inlining of a property node or Invoke node which is fed with a reference (which does not originate from a local object i.e. a static reference to a FP object) then it should be inlineable.

This is a bit of a pet peeve of mine while programming, a tunnel placed at the midway of a structures edge will be covered by the resize handle when you want to move/select the tunnel.  It would be nice if the tunnel had precidence over the resize handle on the structure, and as such would be cover the resize handle so that you could more easily access the tunnel instead of the other way around like it is now.  If you need to resize the structure, there are handles at the edge of the structure, and a Ctrl press while resizing will lock the regrowth to one direction, so the center handle access really isn't as needed.

 

Tunnel 1.png

As it currently is

 

Tunnel 2.png

Would be nicer like this

When typing into the Quick Drop search, unless the query string is an exact match to a result, nothing is highlighted in the results list, which throws the following error when trying to drop an item:

 

Merge-Errors-Quick-Drop  "Mer err" is typed, then *click*, produces:  Mer-Err-Invalid

 

It would be nice if Quick Drop always highlighted the top match in order to always have a droppable item.

 

This would make Quick Drop behave like the Win7 Start Menu search - it always highlights the top match, so that pressing "Enter" always has something to invoke:

 

Windows-Start-Menu-Quick-Drop

Having a continuous integration system is an essential component of software development:

Continuous Integration ProcessContinuous Integration Process

This system requires automating the building process.

The LabVIEW development environment unfortunately does not have built-in tools to achieve this easily.

But the community has supplied a few sollutions to achieve this: CLI Tool

 

On of the biggest hurdles that yet remain, is the fact that the application builder is inherently tied to the development environment.

This requires a valid license for the environment and all toolkits / technologies used in the source code of the product you intend to build.

 

My proposal would be to have a special "CI" license in which all required modules and toolkits are activated, and that would allow the development environment to launch in some sort of protected mode that prevents users from actively developping code (while still allowing scripting functions), for the sole purpose of building applications.

Apparently VI Analyzer toolkit doesn't support any 64bit LabVIEW version, this is really something I miss!

 

With all the good reasons to use it that NI gives it's hard to understand!