LabVIEW Idea Exchange

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!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Compatibility Modes

Status: New

There have been several ideas proposed to alleviate accidentally savings vis in the wrong version of LabVIEW. While useful, I think the main problem is that LabVIEW doesn't use the information it reads from the file to preserve compatibility. I'd like to propose here that LabVIEW introduce compatibility modes for previous releases in which LabVIEW will break a VI if a feature is introduced that isn't supported by the compatibility version. It will essentially be a built-in, seamless "save for previous" mode. 


By default, LabVIEW will load a VI (hierarchy) in a compatibility mode for whichever version is was saved in. If the user tries to make a change that isn't compatible, LabVIEW will alert the user and the user can tell LabVIEW whether it's ok to save to a newer version that supports the feature.


The level of alerts can be configurable, of course.


Related ideas:

Version-aware LabVIEW launcher

Add header to LabVIEW file to contain the version of LabVIEW

Display VI version in title bar

Version independent Source Code Saves

Proven Zealot

I like this idea.


Very much actually.


What about feasability?

NI Employee

NICE1! would be great for VI-revison, especially for support.

Active Participant

I was about to post a similar idea, but think this one (which I kudoed a long time ago!) is close enough.  This idea seems even more feasible now that compiled code is very often separate from the VI.


My addition to this suggestion is that when saving a VI (with separate compiled code) for the first time, the default VI version is the earliest one which contains all the functions used in the VI (but not necessarily in subVIs).  Then, as this idea states, that version would be maintained in further editing unless features are added which are only present in newer versions.  There seem to be no benefits to restricting to the current version if it is not required.  If there was a menu in the Save As dialog (or in the File Properties I guess) with compatible versions, then individual files could easily be saved back without creating a new VI source tree.  Also helpful would be a VI Method "Save For Earliest Compatible Version" or similar.


It's also frustrating to have Projects update to a new version, when the XML is still compatible with earlier versions - yes, you can manually edit the version number in the file, but it would be nice not to have to.

Active Participant

I think the idea of saving the last compatible version is a good one. It's exactly what the Zip format does with bytes 4 and 5 of its header, indicating the minimum version needed to extract, which is determined largely by the compression method used. Similarly, the VI could indicate the minimum LabVIEW version that is needed to support its internal workings.

I think in the case of separate compiled code, the VIs should be much more version-agnostic as far as practicable.

Ryan R.