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

Make a 'best-effort' attempt to open newer VIs/LVLIBs/etc

Status: New

Could it be possible for LabVIEW (even if only for versions 202{1,2,3} onwards etc) to make an attempt to open newer files and just break them when new features are used?

 

The comments in this Idea (LabVIEW Compatibility Modes) suggest this and related ideas, but it isn't the main part of that idea, so I'm posting it separately here.

 

An ideal solution for me would be for VIs to automatically save back in the 'oldest' version that they would support (and perhaps not be 'up-compiled' on load), but this idea has been discussed a few times and doesn't appear to be something NI will support.

 

An alternative (perhaps only possible in currently unreleased versions?) might be to have LabVIEW 202x try and open a VI saved in 202<x+n>, and then give the symbol for missing VIs (ideally with the name, if possible) for anything that isn't supported.

 

As an example, trying to open a VI using Insert into Map (if this were available for existing LabVIEW versions) in LabVIEW 2018 could produce something like

cbutcher_0-1596430804139.png

with the Context Help giving me a clue as to what was lost - I could then Google "Insert into Map LabVIEW" and try guess how I might replace it (here, probably with Variant Attributes).

 

I'm posting this idea in relation to some comments I've recently heard regarding sharing and packaging code with LabVIEW, and how even when other (text) languages add new features and so code using them will fail to compile, their users/developers can still open the code, try fix bits, or generally workaround issues (and evaluate the benefits of upgrading, if the changes are large).

New versions of LabVIEW continue to have significant new features, so upgrading seems like it will continue to be at least my preference, but not everyone has the same requirements/situation/SSP/blah blah blah.


GCentral