LabWindows/CVI Idea Exchange

Community Browser
About LabWindows/CVI Idea Exchange

Do you have a feature idea for how to improve LabWindows/CVI? Submit and vote on ideas now!
  1. Browse by label or search in the LabWindows/CVI 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 New Idea to submit a product idea. You should submit a separate post for each idea. Watch as the community gives your idea kudos and adds their input.
  3. Give kudos to other ideas that you would like to see implemented!
  4. NI R&D will review ideas that have been submitted and update the status.

Note: the LabWindows/CVI Idea Exchange is not the appropriate forum to submit technical support questions.

The LabWindows/CVI R&D team is committed to reviewing every idea submitted via the LabWindows/CVI Idea Exchange. However, we cannot guarantee the implementation of any LabWindows/CVI Idea Exchange submission.

Top Kudoed Authors
User Kudos Count
Showing results for 
Search instead for 
Did you mean: 
Post an idea

If a file is listed in a project, but it is doesn't exist anymore on the filesystem, CVI doesn't mark it in any way in the project tree.

If the file is an .uir, this brings to a strange behavior with "Find UI object" (see here).

I think that files non-existent on the filesystem should be marked mark in some way (color, special icon, ...) in the project tree.

The check can be done when the user opens and closes the project.

There are many library functions that return several parameters. Many of which you may not care about. Some functions allow you to pass NULL to ignore some returned parameters, but many do not.

For instance:

LinFit (X, Y, NbP, NULL, NULL, &Intercept, &Err);

if you are only interested in the Intercept and error values, will crash on run with a "Null pointer argument to library function" fatal error.

The way it's currently written , you have to (correctly) declare plenty of dummy arguments for your calls.

The integration of some SCC software is officially supported in CVI (see this KB).

Unfortunately GIT is not officially supported, but its popularity has been increasing very much.

LabVIEW has a specific User Group in the community (Git User Group) and I think CVI should support the same integration


On high resolution monitors, the icons in the toolbar, project tree, and library tree in CVI are really tiny. Font sizes can be configured, but icon sizes cannot.

As usage of high resolution monitors becomes more common, I think it would be very helpful to provide some configuration options to optimize the appearance and usage of the CVI environment on monitors of varying resolution. Please refer to the attached screenshot for an example of this behavior.

This X just closes out of the tab that is on top.


CVI window.PNG


Pretty much every other program with tabs has the X on the tab you’re closing out of. The current placement makes me hesitate every time, because it feels like you’re X-ing out of the entire code-viewing pane, not just the single file you want to close.


It’s also not consistent with the rest of the environment.

For example, in the pane on the bottom in the screenshot above, “Threads” and “Wa tch” look like two tabs, but clicking the X in that pane causes the entire pane to disappear rather than just closing the tab that is on top.

I add this new idea based on the info on this thread.

I know that this idea is almost the same, but the basic reason is quite different.


I think that C++ offers much more flexibility for the development and it is a much more powerful approach for the future.

Now CVI uses CLANG/LLVM compiler, that is a C/C++ compiler.

But, as written by Luis from NI

Supporting C++ entails far more than just the compiler. For example: the standard C++ library (including templates, etc...), the APIs of all the standard CVI libraries, the source editor (auto-indentation, coloring, etc...), code-generation from the various wizards, memory runtime checking, debugging, etc... so, even though the compiler does support it, for all of CVI to support C++ is still an extremely large undertaking that has to be weighed against other, competing work that's going into CVI.



Based on this thread, CVI RT doesn't support the new standalone cDAQ (9132, 9133, 9134, 9135, 9136, 9137) when they run NI Linux Real Time OS.

I think that this support should be added asap because it allows saving CVI code already developed

I would like to propose an idea for National Instruments to come up with a LabWindows CVI Peer Review Form. This form would be used to help a software programmer or engineer review someone else's code to ensure that they wrote the best code possible. It would provide a quick set of questions which the reviewers would need to look for in the code and then answer. The form would help ensure that the code was designed in a format that is easy-to-read, efficient, set up for all possible failures, is as organized as possible, etc. There could be separate sections based on the different types of files, whether it's a .uir, .c or .h file.


This idea is not new, since here is an example style checklist for LabView:




it was very nice to see clang updated to version 3.3 in CVI2015; I wish this support of current versions of clang will be continued in the future, so I am hoping that with CVI2017 we might get clang 3.9 or 4.0 because of the following issues:

- many many bug fixes in clang

- improved diagnostics

- support of C11

- full support of OpenMP 3.1 and beyond



As discussed here, distributing the code of


#include <ansi_c.h>
int main ( int argc, char *argv [] )

    printf ( "%s", "Hello world" );


generated in CVI2013 results in a distribution kit of 74 MB minimum...  Using the NI default settings results in 219 MB...


Yes, I do have TB drives, but I dislike bloated software.

NI is not a C/C++ Editor-Debugger company.  And, it will never be able to invest the man power needed to get there.  NIs strengths are its Instrument UIs, its libraries, and it's visual application UI pieces.  The LabWindows/CVI tool looks and feels like tools from the mid 90's (ie.  like an old Borland C editor, but even less featured).  It lacks the toolset found in VisualStudios, NetBeans, and Eclipse.  And, it will always be behind.


The Verigy93k tester was like this several years ago.  They wrote their own C/C++ editor, and it was at a mid 80's level.  When a team was asked to rewrite the UI and bring it up to date, they made a novel choice (they recognized that they were not a UI platform / editor company), and they moved their product under Eclipse.  Teradyne Flex did something similar a year or two later moving under Excel and Visual Studio.  The thing is this, both companies realized that they could make more money focusing on their real strength.  They added libraries and apis to work in the platforms framework, and changed/adapted the platform framework to work for them.  ie. Teradynes Flex test tool does not say "Excel/Visual Studio", it says it is a Teradyne product based on MS Excel and VS.  And, they have adapted the platform to their needs adding on the extra Windows/UIs/... to meet their needs.  Same with the Verigy 93K.


In Teradynes case, they went back to the drawing board.  So, we will ignore this (even with their success).  In Verigys case, all their existing APIs worked in the new platform, and the user didn't need to change anything when they upgraded.  But, suddenly the Editor and Debugger were up to date, with latest greatest features.  It was a huge change overnight.


LabWindows really should make a shift to Eclipse.  Keep your old legacy stuff at first, but working under Eclipse.  Add in "Views" and "Tools" to supplement what Eclipse doesn't give you for free.  And, remove unwanted or confusing plugins from the eclipse base.  (This is what advantest did.)  Leave in features that make Eclipse great, like error view, and the ability to have several "perspectives".  And really focus the man power into making a product that will blow the others out of the water.  NI has what it takes to make great Instrument editing/debugging windows in Eclipse.  But, NI doesn't have the 1,000's of people and millions of man hours required to make an Editor/Debugger that will compare to the Eclipses/VisualStudios of the world.  As a business they should focus on what will make them a differentiator, and reuse what is accepted and common.


Anyway.  My 2 cents on how you could really improve LabWindows in a few short months.  (Note: Verigy spent all of 9 months and 9 engineers on their C/C++ integration into eclipse...  I know... I was there at the time.)  If you took the LabWindows team, and a year or two...  Imagine how much better of a job you could do.

At present CVI is missing a serious report printing facility that permits to create flexible, professional and good looking reports.

A quick search in CVI forum shows that periodically somebody posts questions about reporting but available instruments at the moment are not satisfactory in my experience.


As far as I can tell, a good reporting instrument:


  1. Should integrate easily with CVI
  2. Should be fully documented, with some example for the more typical types of reports (text + table, text + graph, text + image...)
  3. Should not rely on external programs (some customers have rigid constraints on the software installed on equipment machines; additionally, asking them to have full Word or Excel or Diadem installed only for reporting is just not serious)
  4. Should not rely on ActiveX controls to be licensed separately (same as above)
  5. Should permit to include text and graphics (images, graphs...) and define headers, footers, page numbering and other common features normally present in reports
  6. Should output data directly to the printer or in PDF format
  7. Should have a preview facility both for development and for the user (something that NIReports hasn't and will never have)

A useful CVI GUI tool would be the addition of sideways tree-style tab control.  I am surprised to see no mention of it in the forums.  Is there already some solution for it, or perhaps some Active-X that can do it?    Nevertheless, it would greatly modernize the GUI arsenal.

Allow you to select multiple lines and then go to Edit>>Block Comment/Uncomment to be able to comment or uncomment multiple sections of code at once.



because I had installed CVI2010 on a brand new Windows 7 machine, I was curios to find out about all the service processes running on the system.

It seems that there are quite a few NI services that start after log-on. Some of  them seem superfluous, such as the Lookout Citadel service (no LabVIEW, no Lookout installed), but due to the lack of any information I did not bother trying to stop them



1) NI should critically review the services and only start the services that are absolutely needed.

2) Services that are optional might be selected by a checkbox during installation or from the Options / Environment setting

3) NI should provide some documentation / explanation of each service and why it is needed.



In the last few years JSON came out as new format for data objects consisting of attribute-value pairs, largely replacing XML.

LabVIEW has functions to handle JSON data, and LabVIEW Community has been developing a JSON Toolkit.

In the CVI board of the forum this is the only result for a "JSON" search (at the present).


I suggest to integrate into CVI a JSON library (for example JANNSON).

I think this is better than develop a proprietary library.



there has been the valuable suggestion of a "Picture and Text" button allowing more modern buttons.


For all those focusing on programming instead of UI design it would be also nice if CVI could provide more default buttons ready to use as some examples shown in the image below (taken from the NI community).


As they seem to be already available in LabVIEW it shouldn't be much effort for NI to adapt them to CVI... - hopefully Smiley Wink




Under labwindows CVI 2015, I develop a program using a state machine. For this I use a "switch".
The program is voluminous, and in order to browse it more quickly, it would be very interesting to allow the collapse and the expansion of the boxes in a structure "switch"


Display more struct member information during source editing and during debug.



While editing source code, CVI only displays the struct members, but no information regarding the type of the member (or declaration information, line file and line).

Add a tooltip to the right of the pop-up displaying the struct members in the source editor to display this information. Similar to this picture:


Also add support for displaying nested structs and even display the member values while debugging, in form of a tree, when execution is suspended (CVI currently only displays the memory address of that struct variable).


Since now CVI relies on CLANG, it would be great to have a tool for static code analysis.

Some software are available for C code (see here), but I think CVI can use Clang Static Analyzer (if it is good enough - I've never tried it).