Installing old VIs in newer LabVIEW folder: how to avoid conversion warnings?

[Olf]

We are offering a set of VIs to our users. We build our own installer which installs them into the LabVIEW program folder under vi.lib. A menu file is installed in the menus tor which collects the VIs in a palette.

For providing compatibility with LV 8.2 and up the VIs are in v8.2 format. When they are installed in a higher LV version and a LV program that contains some of the VIs is closed, LV issues the warning that the VIs have been recompiled and converted from an older format. How can we install the VIs so that LV ignores the format version?

[smercurio_fc]

---

@Olf wrote:

We are offering a set of VIs to our users. We build our own installer which installs them into the LabVIEW program folder under vi.lib. A menu file is installed in the menus tor which collects the VIs in a palette.

---

That is the wrong thing to do and a bad distribution method. VIs that you distribute go into the user.lib folder. Do not mess with the vi.lib folder.

---

For providing compatibility with LV 8.2 and up the VIs are in v8.2 format. When they are installed in a higher LV version and a LV program that contains some of the VIs is closed, LV issues the warning that the VIs have been recompiled and converted from an older format. How can we install the VIs so that LV ignores the format version?

---

You can't. If the VIs are in 8.2 then opening them with a higher version will trigger a re-compile. You did not indicate other errors related to LabVIEW not being able to recompile due to the block diagram having been stripped, I can only assume that you are distributing the VIs with the block diagrams. This would be necessary so the VIs can be opened in newer versions of  LabVIEW. Regardless, the VIs will be recompiled. If you set them to read-only then the changes can't be saved, but they still will be re-compiled the next time they're opened.

[tst]

You can basically create your own installer VI which will deploy the VIs to their destination and then open a reference to each one and call the Save Instrument method on it.

If you want, the Code Capture Tool has an example of that, so you can follow the link there to SourceForge and get one of the older versions (e.g. 1.x) which demonstrate this.

Another alternative is what the newer versions of the CCT do, which is to check whether the top level VI has a modification each time it is called and in that case do the save, but I think the first is more down your lane.

A third option is to download VIPM, which allows you to create packages and has an option for mass compiling the files after installation, but that would require all your users to have VIPM as well.

[tst]

---

@smercurio_fc wrote:

That is the wrong thing to do and a bad distribution method. VIs that you distribute go into the user.lib folder. Do not mess with the vi.lib folder.

---

Actually, NI now recommends that VIs do go into vi.lib because (paraphrasing an NI source I can't remember at the moment) "we can do stuff with vi.lib which we can't with user.lib" (or something similar, and no, I don't understand what that means either) - https://decibel.ni.com/content/docs/DOC-8737.

Olf, I suggest you also look at the other documents in that group, as some of them might be relevant to you.

[smercurio_fc]

I was just about to post a follow-up suggesting that the user do a programmatic save when tst came to the rescue. Well, at least I showered.

That's the first document I've seen that says to use vi.lib for the actual source code. The other document regarding add-ons say to use it for "support files", but no mention as far as the actual source code.

[Olf]

---

@smercurio_fc wrote:
You can't. If the VIs are in 8.2 then opening them with a higher version will trigger a re-compile. You did not indicate other errors related to LabVIEW not being able to recompile due to the block diagram having been stripped, I can only assume that you are distributing the VIs with the block diagrams. This would be necessary so the VIs can be opened in newer versions of  LabVIEW. Regardless, the VIs will be recompiled. If you set them to read-only then the changes can't be saved, but they still will be re-compiled the next time they're opened.

---

How do I set them to read-only? You don't mean setting the write-protection flag of the file, right? (It doesn't help). Or do you mean the VI protection mode?  If I set the mode to locked (no password) in LV 8.2 and save the VI, I still get the "unsaved changes..." warning when I close a project in LV 2011 that contains it.

The block diagrams are not stripped btw.

I should have said that we do not put the VIs in a LLB or library. They are installed as single files in a vi.lib/Company/Product folder. Should we use a lib or a LLB?

Olf

[smercurio_fc]

I did not mean to imply that setting the read-only flag would fix your problem. Only that it would prevent the file from being saved, if that's what you were intending to be done. You cannot change the behavior, as it is by design. You can deal with it by compiling the VIs when you install the software, as has been mentioned. Or, you can distribute pre-compiled versions in the LabVIEW versions of your choice.

If you install the files as individual files then I hope you are using names that are not likely to cause name collisions when a user tries to name their VI with the same name you happen to have chose for one of your subVIs (like "Read Values", or something like that). Project libraries will allow you to namespace your VIs to prevent this name collision.

[Olf]

---

@smercurio_fc wrote:

I did not mean to imply that setting the read-only flag would fix your problem. Only that it would prevent the file from being saved, if that's what you were intending to be done. You cannot change the behavior, as it is by design. You can deal with it by compiling the VIs when you install the software, as has been mentioned. Or, you can distribute pre-compiled versions in the LabVIEW versions of your choice.

---

You mean it is definitely not possible to have VIs in one, relatively old LabVIEW format and install them for newer LabVIEW versions without getting this (completely useless) warning? This is hard to believe. How do other companies distribute their LabVIEW programming interfaces? Do they really maintain a VI versions for every LV version (and possible sub-version) just to guarantee a good user experience?

Since the recompiled changes are dumped anyway, I would expect a VI or library flag I could set or a special way of installing the VIs that tells LabVIEW: ignore the changes when the VI is closed.

Recompiling everything during installation is not what we want since it would make the installation process too complicated, in which our LabVIEW API is just a small part. If nothing else works I would rather install the VIs writable so the user could just hit "save all" when he closes his program and get rid of the warnings, but this is not optimal.

Olf

[smercurio_fc]

It is not a useless warning, nor are the changes "dumped". They are only "dumped" if you elect to not save the VIs. The changes are real. The VIs are recompiled in the new version. As has already mentioned, this is by design. Newer versions of LabVIEW change the file format, and consequently the files need to be resaved in the new version. If they are not, then they are recompiled again when you next open them. Also, newer versions of LabVIEW can deprecate certain inputs to VIs and/or functions. Recompilation ensures that they will work in the new version.  Additionally, newer versions of LabVIEW can eliminate old VIs and/or functions alltogether. Again, recompilation will tell you this. You would like to know this, wouldn't you?

I don't see what's so complicated about performing a recompilation when you perform the install. The Code Capture Tool, as tst mentioned, does this. As an end-user I don't see a problem with this. But then that's because I understand what's going on, so it's not a surprise to me, and I expect it. For users who may not understand this then perhaps a little explanation in the installation instructions, or perhaps a simple dialog during the installation process would be warranted.