LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW 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 Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
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!

Post an idea


When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.


Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

It would be nice if LabVIEW automatically check for updates and notifies the user of all of the upgrades available for everything that they have registered. It would be nice if patches were just down loaded and installed much like the Windows Updater function. It would keep LabVIEW, all of the tool kits, Measurement and Automation Explorer, and every licensed software up to date. It could also push down labview as long as you are on the subscription and current.
Builder should automatically attach version of LV to EXE so it can be seen in Windows Explorer. So you can always ask unexperienced end user about version. I drove 1000 km with wrong version of LV on my laptop... Upgrade to new version is not always straitforward... And I always forget to set version information manualy...

For modern application development we need better methods to detect wheter our application is called to open a file.

Currently the only help NI gives is based on command line parameters. And we need to jump through loops to get it working to react on opening a file when the program allready runs.


This is a major showstopper in creating professional applications.


LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.



I haven't checked out LV2009 on Mac yet, so please let me know if this has already changed.....


When creating an installer on Windows, we have control of everything within the Project.  Cereate EXE, then create Installer with all options within the project.


On the Mac we have the options for the Application but not for the installer.  I know (After I spent a day looking for products) that Apple has an installer packager which ships with the OS (On the developer CD) but why can't we automate this from within the Project shell?  As it is I need to create the Application, then switch to an external program, create the installer (luckily it's relativel easy o use) and then to finish things off go to ANOTHER pogram to create the dmg file.


Please give the Mac the same Installer creation options as Windows.



Dealing with fonts in LabVIEW can be a nightmare due to the variations in fonts, types of fonts, rendering variations, resizing, etc.  If you are deploying a LabVIEW application on another machine, frequently the fonts or settings on the target machine don't match; creating a very ugly looking panel.


When developing for Windows in the past I have always edited my LabVIEW.ini file  to include the following:


appFont="MS Sans Serif" 13
dialogFont="MS Sans Serif" 13
systemFont="MS Sans Serif" 13


And when deploying an application; I include these in the app's ini file also.


This seems to work for most windows targets since MS Sans Serif appears to be a common font.  I suspect this will produce unpredictable results in OSX or Vista for that matter.


What I expect as a developer is not having to deal with these font issues.  I expect that when I develop an application that it has the same look and functionality; regardless of where it is deployed; even as a VI being edited on another machine with different font settings.  This means that the font information must be encoded and stored with the VI itself.  I would expect that both the LabVIEW editor and run-time engine would be able to recognize detailed font encoding within the VI and adjust the display accordingly based on the local machines font capabilities.  This is what one expects when printing or viewing an Adobe Acrobat PDF file; and the behavior of LabVIEW code; particularly since it is so graphical in nature; should also be similar.  I wouldn't expect that the actual font bitmaps be stored within the VI itself; but some detailed metrics about the font should be; height, width, kerning, etc.  Thus if a font substitution takes place when being deployed on another machine; at least the text will occupy the exact same extents as the original.


Though I don't know exactly what the detailed implementation would be; it does need to be transparent to the LabVIEW programmer, i.e. zero code; zero hassle; zero worries.  It should just work.  I hope we can all agree on this.

We are getting into trouble with all these run-time engine updates! Every time a new release or service pack come out we have to create a new installer with the new run-time engine and send it out onto all our customer's machines. It is not convenient to develop in 20 different versions of Labview and we like to keep our executables and updates recent.


Our instruments run on XPe with very little extra room for an additional RTE every 6 months. Asking the customer to uninstall old RTEs is painful as they are not supposed to go that deep inot our XPe build. 


I would like to see a modularized run-time engine where we don't need to update the whole thing every release. I know  with .NET updates are only necessary in 3-5 year increments. That would be much more acceptable IMHO:smileyhappy:


As outlined in a post in the NI forums HERE, and seeing as I'm currently being forced to re-install several LV versions on my Laptop (Have been doing so since yesterday!) I want to re-iterate my affinity for having LV installed in a Virtual PC.


Memory problems, Hard disk crashes, Virii, stupid user: there are many reasons why an OS would need to be re-installed.  In my case it happens that my HDD was on its way out.  I think this may be linked to many crashes I have been experiencing over the last 8-9 months.  I am nor re-installing ALL of my LV versions.  This is a major pain in the tuchas.  I have backups, but I would rather re-install since I don't know when the data corruption started.


Being a nice law-abiding citizen (or a sucker, depends on who you ask) I don't want to violate NI's EULA by installing each LV Version (Ideally each quarterly update)on a separate VM.  This violates rather quickly the "install on 3 PCs rule").


Please please let us install on many Virtual PCs as long as they are not distributed amongst other users.....


Did I say PLEASE?





I work as a LabVIEW integrator and for one of my customer I develop application, with maintenance goal for their installation all over the world with RS232 or Bluetooth communication for example, deployed on targets as PDA (PocketPC 2003 & Windows Mobile 6) or Touch Panel (Windows CE 4.2 to 5.0) using LabVIEW 8.6 Mobile Module.

This LabVIEW additonal module works quite well to deploy the same application in this differant targets, but I encountered some problems and I have some suggestions for Mobile Module :


1/ MMI (Man Machine Interface)

      -  for graphics indicators (as Gauge or Slide) graphical object ramp or multi Slider is deleted by LabVIEW when you build an EXE => I think that a graphical objets with all its graphical property could be added in Mobile Module (and works on these all targets). See examples in GraphicalObjects.PNG

      - as I say in my introduction my application is deployed all over the world and usually I used "Caption" dynamic modification for multilingual management for all my controls & indicators. But in mobile module we can't do this (but we can modify dynamically boolean text), so I think that it could be possible.


2/ VISA (& Bluetooth) Management

      -  I think there is a bug with VISA installation. Indeed with the installer you can choose the installation directory (default directory or specific directory : in non volatil memory) but if you don't install VISA support in default directory it doesn't work (with PocketPC 2003 for example) I think that could be resolved

-  As I said in introduction my application could communicate throught different protocols (RS232, Bluetooth) and with LV 8.6 Mobile Module we can now use VISA : great !!!. But in Windows Mobile 6, VISA does not support bluetooth (it seems to have an incompatibility with virtual aliases in the registry) ; and in PocketPC2003 it works very well. I think that could be resolved

I like using Linux whenever I can, particularly when running large software like LabVIEW, since it tends to crawl on my XP systems. I was happy to realize that LabVIEW works on Linux, but soon after I was disappointed by the lack of usefulness of it when interfacing with hardware. I need to use the RealTime module to interface with my RealTime Compact-RIO. I also need Linux support for the FPGA module, as I need to program the FPGA attached to my cRIO. I'm sure I am not the only person who would like the ability to do this.


Without support for any of the hardware or LabVIEW modules I need, the Linux version of LabVIEW is entirely useless to me, and XP as an OS simply cannot perform up to par for me.

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

Using Google Apps and similar products I've come to really love the access I get to all that functionality regardsless of which computer I'm on.  Imagine how great it would be if you could have LabVIEW available in the same way!


All the work, your VI libs, the compilation etc. would be on the hosting server (sharing VI libs, source code control and collaboration in general could be made very flexible indeed). There would be a few challenges to overcome, e.g. when you are writing code for different targets, but nothing unsolvable I think...(if there are any show stoppers we could have both...a web based editor as well as the traditional solution).


And the host could offer you to work in previous versions of LabVIEW...and new versions would be available as soon as they are launched, and you could build apps for different operative systems in one go.... no volume license manager headaches...the list of possibilities and improvements is endlessSmiley Happy