New Feature: Developing a LabVIEW Project in an Older Save Version File Format

[Christina_R]

Note: this post is related to the "first phase" of feedback on this feature. The "second phase" in the LabVIEW 2024 Q3 Beta is here: New Beta Feature: Developing VIs that Can Be Used in an Older Version of LabVIEW - NI Community

------------------------------------------------------------------------------------------------------------------------------------------------

Note: Although we are using the Beta forum to gather feedback on this feature, the functionality is in the released LabVIEW 2024 Q1, and can be enabled with a config token. Note that this Preview feature is not a fully-supported feature of LabVIEW 2024 Q1 and is Beta quality.

This feature allows you to use LabVIEW 2024 Q1 to edit VIs that can be opened with older versions of the LabVIEW editor. This allows you to collaborate on a project with others who haven’t upgraded to the same version of LabVIEW that you are using.

Section 1. Enabling the Preview Feature

• (Windows) In the LabVIEW .ini file, add the line: FeatureToggle.Editor.ProjectSaveVersion=True
• (Linux) In the labview.conf file in ~/natinst/.config/LabVIEW-2024, add the line:
  FeatureToggle.Editor.ProjectSaveVersion=True

Section 2. How to Use the Preview Feature

For this feature to take effect, VIs must enable the property “Separate compiled code from source file” (found in VI Properties>General).

In the Project Properties dialog box, in the Project category, you will find a new “Save version” option. You can set the option to LabVIEW versions back to 2017 (“17.0”).  Selecting “Editor version” (the default) will save files in the format matching the editor, which matches LabVIEW’s former behavior (without this new feature).

You can also set a Save Version on Libraries. When editing a VI, the Library setting (if configured) will be honored before the Project setting.  The default save version setting for libraries is “Default” rather than “Editor version”, which means it will inherit the save version from the project setting (when editing within a project) if not set explicitly.

When editing a VI that isn’t saving in the current editor version, there will be a new “Save version” element on the toolbar that shows what save version has been specified. However, LabVIEW will not save to that version if it is not safe to do so without losing information. If a VI is using unsupported features, it will instead save to the oldest version that supported everything in the VI.  For example, if a VI uses sets or maps, it will save in at least version LabVIEW 2019 (“19.0”) even when set to save to an older version.  This ensures that saving will not lose VI contents the way that Save-for-Previous can.

If a VI cannot save to the designated version, the toolbar “Save version” item will show in red text with a warning glyph.  You can hover over the item to see which compatible version will be used instead.   You can click on the element to open the Error List Window, which will contain a new section called “Save Version Compatibility Issues.” As with errors, you can double-click on an item to locate the code and make edits to resolve the issue.

Section 3. Caveats and Limitations

We expect you to edit VIs within a project or library to use this feature.  However, as an advanced feature, you can also set a save version on an entire directory by creating a file called “.lvversion” in the directory. The file should contain a single line specifying the save version as text, such as “21.0”, and it will affect all VIs loaded from that directory or any contained subdirectories.  If a VI is also being edited within a project which specifies the save version, the oldest of the two versions will be used. If the save version is defined by an owning library, that version will supersede either project or file-specified save versions.

If a save version is configured for a given project or library, LabVIEW will honor it even if the feature toggle token is off. The feature toggle disables the ability to change the version in project settings.

Application Builder

• LabVIEW-built applications, shared libraries, and PPLs will still be saved in the editor version. For Source Distributions, the save version specified in the project will be used only if the source distribution is configured to save VIs as source-only (“separate compiled code from all source files” in the Additional Exclusions category).  The feature does not support saving embedded compiled code in VIs compatible with older versions without recompilation.

LabVIEW Real-Time

• Note that your RT target will still need to match your editor for deployment, even if you are authoring VIs in an older version file format.

Section 4. Known Issues

1. If VIs are not set to “Separate compiled code from source file,” there is no feedback that the requested save version isn’t being used.

[Ray.R]

Thanks NI!

This is a long awaited feature.

[wiebe@CARYA]

If I open an old VI, it doesn't save (as advertised) so that's a big win.

However, when I change the old VI, the close "explain changes" doesn't mention it got converted. It only lists the change I made.

Seems like a cause of confusion. I'd assume there won't be any conversion because it isn't mentioned.

[Christina_R]

I'm sorry, but I'm afraid I don't understand. If you're opening a VI that's not in a Project with a specified save version, there's no change from the behavior in prior versions of LabVIEW.

Can you please clarify if you're working in such a project, and what kind of conversion you're expecting to happen?

[crossrulz]

---

@Christina_R wrote:

I'm sorry, but I'm afraid I don't understand. If you're opening a VI that's not in a Project with a specified save version, there's no change from the behavior in prior versions of LabVIEW.

---

That's the problem.  The expectation is that when you open a VI, it will stay in the version it was last saved in unless we explicitly choose to update it to the latest.

Example here is I am trying to help someone on the forum.  They give a VI saved in 2019.  If I open it up in 2024, update it, and save it, we want the VI to stay in 2019 so that the OP can just open up the updated VI.  Instead, we have to do a File->Save For Previous, which creates a copy of the file.  This is another file we have to delete just to help somebody on the forum.

With that said, I am still in the process of installing 2024Q1.  I can give better feedback when that is done.

[Darren]

In that scenario, I would create a project, change the save option in the project to 2019, then add the 2019 VI to that project. Now when I change the VI and save it, the VI will still be saved in 2019 format.

Still a couple of steps above having the editor "just know" to save it in 2019 (which would be a great evolution of the feature), but in my opinion easier than SFP.

[crossrulz]

---

@Darren wrote:

Still a couple of steps above having the editor "just know" to save it in 2019 (which would be a great evolution of the feature), but in my opinion easier than SFP.

---

My expectation is to have the ability to set the save version at the VI level.  LabVIEW can detect if the VI is in an older version.  So when a VI from an older version is opened, display the version in the toolbar and make it selectable from that button.

[Darren]

---

@crossrulz wrote:

---

---

My expectation is to have the ability to set the save version at the VI level.  

---

In my opinion this feature is better implemented at the project-level. I equate it to 'auto error handling' and 'separate compiled code', which are VI-level settings, but I don't think they should be. As someone who uses the Project Explorer to organize my code (primarily in libraries), I would be just as frustrated to encounter random VIs in my project with different save versions as I am present-day at VIs with random auto error handling and separate compiled code settings.

One of the things that NXG got right was putting auto error handling enable/disable at the project level.

[Craig_S.]

---

My expectation is to have the ability to set the save version at the VI level.  LabVIEW can detect if the VI is in an older version.  So when a VI from an older version is opened, display the version in the toolbar and make it selectable from that button.

---

Unfortunately, there are some issues that make implementing this feature at the VI level a bit problematic.

The save formats of previous LabVIEW versions are fixed, and the only version information saved in the VI are the 'API' and Editor versions of the LabVIEW instance which saved them.  So outside the project settings (or a file system/folder-based override), the only information we can retain about the preferred save version for a VI is the current version it's already saved in.

So in order to implement something like this, we'd essentially have to have a global behavior change (possibly behind a Tools->Option setting or ini token) which caused VIs to automatically retain their original save version on load.  The issue is that without a project or something else providing a "source of truth" giving an explicit version specified by the user, the feature of detecting and warning when the user uses features not supported in that version is not well-defined.   If we allow the user to click on the state panel version number and change it, we can only remember that information in memory until the VI is actually saved, in which case it becomes the VI's save version on disk.  But what happens if the VI is later added to a project and the project's setting conflicts?  Since there is no place to save (in an older save version format) the preference of overriding the save version for a specific VI, the project setting would have to always override the VI.   This means the version would only be clickable when the VI is not in a project, or at least, not in a project with a save version set explicitly, which would be confusing, and it's not clear how the transition should work, or how the version-incompatibility reporting might need to change.

Because of these kinds of issues and other usability problems that could arise, setting the save version at a per-VI level will not be supported for the first release.  That said, I do understand the potential convenience of what you propose.  If we can work out viable solutions to these issues, I wouldn't rule it out for a future enhancement.

---

Craig Smith
Chief Software Engineer, LabVIEW R&D

[jyoung8711]

I'm very excited about this feature! 

The first thing that jumped out at me, was my expectation would be that if a project is loaded from an older version, that the auto-selected option in the Project Properties would be THAT version rather than the "Editor Version" that's currently selected.

For Example: I loaded LabVIEW 2021 project, I would want the "save version" property to be "2021" not "Editor Version".  So that the default behavior if you click save/save all, would be to continue to save in the original project. 

The "current save version" is saved in the project file (I personally will open up the project XML sometimes to see what version I should be using), so I would expect this would be possible.

If this behavior is not expected to be the default behavior by the average user, then it would be nice to include an additional LV Option (or INI file) to make this behavior default.

It would make accidentally saving a LabVIEW file/project into a 'wrong' editor version much harder... it would then be a deliberate decision, which I personally would definitely prefer.