Under review
Steen Schmidt (GPower) 4 years ago • updated by Timothy Vargo 3 years ago 4
We often have enquiries from our customers to make available a version of our toolsets for an earlier version of LabVIEW than the VIP was developed for. We don't want to develop all our toolsets with LV 7.1 for instance, just to make certain all our users are covered, and it's a huge task to down-save all our toolsets and make new VIPs for those versions. The user also has a hard time doing this, as a simple "Save for Previous Version" doesn't cut it, as the user has to manually recreate the palette in the process (which many users don't know how to do).

VIPM currently allows the user to install for the LV version that the package was developed for, and for later versions as well if we have configured the package to allow this. VIPM uses Mass Compile for this (unless the user has disabled Mass Compile in VIPM of course). I suggest one of two changes:

1) Either allow the end-user to install a package for an earlier version of LabVIEW than the package was built for. This requires the user to have installed the lowest LV version that the downloaded package demands, as well as having installed the target LV version as well. Then VIPM could use the "Save for Previous..." method and re-create the palette for the user.

2) Or, allow the VIP-developer to build packages for earlier versions of LV than the VIs are developed for. This poses the same requirements on the developer, having both the source and target LV versions installed, and would enable VIPB to use "Save for Previous..." when building the packages.

I prefer 2), as that basically automates the process I'd otherwise go through to make our VIPs available for earlier versions of LV, but without me having to handle duplicate build scripts for VIPB. And it puts fewer requirements on our end users.

Best regards,
Steen, GPower
Adding a "Save for Previous" in the package build script would be nice.  One problem you may run into is that you can only save back to 8.0 in current versions of LabVIEW.  You have to have LabVIEW 8.0 in order to save back to 7.1.

My use case was when I was developing a reuse library in 2011, but it was decreed that the library should be in 2009.  I wrote my own VI to save for previous that I ran before performing the package build.
Either VIPM could limit the "backsave" to what is available in the LV-version that the package is developed for, or it could offer multi-stage backsaving as far back as there is installed LV dev versions.

I have made such a VI for backsaving several times as well, and it has to take into account that you don't want to drag with you anything from Program Files (user.lib, vi.lib etc.), it has to make sure that you end up in the proper directory for package building and such. It seems I have to take a new thing or two into account each time I do this "backsaving" VI, and/or I end up patching something anyway after that VI has run.

If such a feature was available in VIPM itself we wouldn't have to make these tools ourselves (obviously :-)).

Under review
Since you guys have the code already, can I have it? :)

There are many things that can go wrong with Save As. It's not clean cut. Solving this problem on the package install side would be very difficult. Even on the development side. You need to do testing to make sure the new source actually works. If the down-save from VIPM fails even once, then nobody would use it. It won't be trusted and that's wasted development.

Are you spending a lot of time saving for previous? Then perhaps you should just develop in that version. I think right now, it's common to develop in LV2009. That's a recommended starting point for most tools. If your tool has some special LabVIEW version specific features then it can't be down-saved anyway.

This is a fair request. It's just impossible to get it working to the point which people would actually use it. Besides, some forethought in developing the tool and some education on the customer's side to upgrade LabVIEW doesn't hurt.
I came here to make this very suggestion (solution #2) if it were not already suggested (which it is).  I agree with Michael that solving this on the package install side (solution #1) invites too many problems.  However solution #2 is exactly what I need.  There are some scenarios that require me to develop a solution in a more recent version than what the tool must be backward compatible to, so developing in the older version is not always an option.  Sure, the "Save for Previous Version" method might certainly fail sometimes; but then VIPM could detect the failure and alert the developer.  Getting the backsave to work properly would then be incumbent upon the developer, but this would be true with or without the help of VIPM.  I'm voting for this!