Preview Feature in LabVIEW 2024 Q1: Developing a LabVIEW Project in an Older Save Version File Format

[wiebe@CARYA]

---

@Darren wrote:

---

@Craig_S. wrote: We definitely should make this easier to do (without 3rd party packages or writing your own scripting code being required). 

If I'm understanding the request correctly, you can change the Source Only setting for all the files in a project by right-clicking the top-level .lvproj item in the Project Explorer and selecting Properties, going to the Project page, and clicking the Mark Existing Items... button:

---

My main concern was if you can set this in LV24, or if it needs to be set in the original version before opening in LV24.

Also, what happens if the option is off?

Both questions come from the fact that it was not exactly clear what is wrong, and that might be the result of things that are already fixed.

Still, in general, a statement (like "SCC should be on") should ideally be accompanied with a consequence. Even more general, we'd need to know (at some point) exactly how this works, down to the last gory detail. Of course, we (the community) will figure it out eventually.

[Christina_R]

---

@Petru_Tarabuta wrote:

3. Is there a "VI Properties Editor" VIPM package?

---

There is a third-party solution for bulk-editing VI properties, but it's not free: Property Inspector Toolkit for LabVIEW - Download - VIPM by JKI

[Darren]

There is also a free version of Property Inspector: Property Inspector Free Toolkit for LabVIEW - Download - VIPM by JKI

[Craig_S.]

---

My main concern was if you can set this in LV24, or if it needs to be set in the original version before opening in LV24.

Also, what happens if the option is off?

Both questions come from the fact that it was not exactly clear what is wrong, and that might be the result of things that are already fixed.

You can set source only in the project and mark project items in LV2024, and then set the project version.  It should load all the project items so that they will get doc mods and ask to save on project close if they need to save in the earlier version.  Doing it in the other order should work too.

If a project has an older version set, it will only affect VIs and libraries which are set to source only; each project item is considered independently, so if you have a mix, the source-only items will save in the set version (or nearest later compatible version based on its feature usage) and the non-source-only items will save in the editor version.  Items which cannot save in the desired version, including for the reason of not being source-only, will show up in the Error List window in the Save Version Compatibility section.  (As you noticed, there's a bug in the beta where we do this for PPL contents, which should be skipped as they will never be saved.)

Older projects loaded without a project version explicitly set will keep the same version they were originally saved in only if the project itself is set to use source-only for new items.  Note: this project source-only check is not in the 24Q3 beta but will be in the release.

[Petru_Tarabuta]

Thanks Christina and Darren. I'll check it out.

[wiebe@CARYA]

So at least in the LV24Q1, there's a problem with enums.

My project is set to LV21, the class is set to LV21.

If you right click a control (in a VI in a class), and select "Make Type Def", the control is saved as a LV24 ctl.

I can add the enum to the class (which isn't done by default), but that doesn't help.

Right click on the class New... Type Def creates a LV24 control. 

Right click on the class New... VI creates a LV24 VI. 

For the right clicks, that might be fixed in the update. But the type defs are somewhat special, as they are not created in the class.

[Craig_S.]

---

wiebe@CARYA wrote:

So at least in the LV24Q1, there's a problem with enums.

My project is set to LV21, the class is set to LV21.

If you right click a control (in a VI in a class), and select "Make Type Def", the control is saved as a LV24 ctl.

I can add the enum to the class (which isn't done by default), but that doesn't help.

Right click on the class New... Type Def creates a LV24 control. 

Right click on the class New... VI creates a LV24 VI. 

For the right clicks, that might be fixed in the update. But the type defs are somewhat special, as they are not created in the class.

---

This isn't special to classes, it has to with saving untitled items that have never been saved before.  It isn't fixed in the beta, but will be for release.  You should be able to work around it by just saving the control or VI again explicitly.

[Mads]

Uisng this feature in 2024Q3 we have the issue that if we want to keep the project in a previous version (2022 in this case), but build the application in 2024 for testing purposes, it takes forever to do the build. I have yet to finish it as it just gets stuck for hours. If I change the version of the project to 2024 and re-run the build, everything runs at a normal pace and finishes as it should (still slower than it used to in 2022 e.g., but OK).

Is there something we can do to get this working? As it is now collaborating on a project across versions gets difficult because test-building the application always has to be done in the previous project version...

[wiebe@CARYA]

I also had some problems with PPLs.

My PPL can't run in the newest run time available (because of the borderline bugs in LabVIEW), so I need to untag this option. But while the source code can be loaded in the newer runtime, the PPL simply won't work. Bottom line is this prevents working on older projects in newer versions.

This is a corner case, caused by problems that keep piling up... The reported errors are vague at best.

The option "allow newer run times to execute..." desperately needs improvement, for exes, dlls and ppls.

DLLs and PPLs should be able to run in the RTE of the environment there's in. They should never run in the newest RTE that is available.

If this was (finally) fixed, the PPL in newer version problem would disappear.

[Mads]

No PPLs in our projects. There are some lvlibs and classes, but they should not be as challenging as PPLs. Overall the workflow for this feature seems to have some holes and weaknesses, unfortunately I did not test it enough in the beta phase.