LabVIEW
Save all requires manually clicking OK on all password-protected VIs.
I mass-compiled in LV2024Q3 after upgrading. Now, when saving all, I have to click OK a hundred password-protected VIs, one by one. And it tells me I must enter the password, but does not let me enter a password, and there is no option to ignore all.
Who thought this was a great implementation? Please fix!
(Text: LabVIEW: (Hex 0x600) To save a password-protected VI for a previous LabVIEW version, you must enter the password. Cannot save VI)
So, LV2024 does not update/recompile password-protected VIs anymore (?). Just hope that works. The very reason I recompiled all is I had a nasty LabVIEW bug when/because I upgraded to 2023 (or maybe 2022) that was solved by a mass-compile. Hope this means NI knows that this will never happen again (NI also recommends mass-compile after upgrade).
@thols wrote:
Now, when saving all, I have to click OK a hundred password-protected VIs, one by one.
(Text: LabVIEW: (Hex 0x600) To save a password-protected VI for a previous LabVIEW version, you must enter the password. Cannot save VI)
Are you sure you did Save All and not Save for Previous Version, which is right next to it on the menu? It's hard to confuse the two, because SFP has an additional dialog, but we know users sometimes just click OK even with dialogs that have additional controls.
That said, I don't know why SFP would require the password either, nor why it would not allow entering the password or canceling or saying skip all. I agree that it's not good UX.
If you want a mass compile, try Tools>>Advanced>>Mass Compile, which I believe also saves the VIs, but it has been a while since I used it.
My guess is that you used the new 2024 feature to keep your VIs, libraries or classes at a previous version than 2024 and as that internally invokes the Save for Previous operation for the VIs, it runs into the protection to not save password protected VIs to an earlier version without having you provide the password.
Workaround might be to open one of the password protected VIs once and enter the password so that it gets stored in the session password cache. Or to disable the "Keep in previous version" feature. Or disable the password!
You should indeed not keep your development VIs with a password. This should be only done as part of building your distribution package and you should never ever edit such a distribution, any edits should always be done in the (unprotected) source code.
Also, VIPM will need to learn to disable the "Keep in specific source version" flag when saving distributions. And for that LabVIEW needs to provide a flag that VIPM can invoke to disable that feature. Otherwise customers will run into difficulties when installing a package in LabVIEW 2024 or newer since they will honor that flag when saving VIs and that will confuse Application Builder when building the internal archive for EXE, LVLIBP and DLL files since the VIs are not in the correct version that the runtime expects and the build fails.
Why would SFP refuse to back-save password protected VIs without providing the password? Basically the password protection was improved (made more complicated) several times with new LabVIEW versions so backsaving VIs without knowing the password could be a means of trying to circumvent the password protection. The earliest password protection (ca. LabVIEW 7.0) was really trivial. Later ones made the hash calculation more complex but as we all know it has been cracked again and again. It was a nice idea but there were very practical limitations how secure it could be done without creating a protection that makes the feature totally useless.
It's mostly like a "Do not trespass" sign at the front door, not a security guard shooting everyone trying to actually trespass. 😁
The password-protected VIs are from a legacy software package with lots of generic VIs, but for some reason is password-protected (maybe the creator intended to sell the code or didn't want anyone seeing how it was solved, who knows). Bad decision from someone a long time ago and I would gladly replace every old password protected VI, but not a quick task.
If the old password-protected VIs are in or out of SCC shouldn't really matter, other than if they are included in my mass-compile, right? If I move them out of SCC, can I safely let them stay at the old LabVIEW version? It should say yes, but since I had that nasty bug show up after updating to LV2023, on code that was not mass-compiled, I'm not so sure that it cannot happen again. (the bug had something to do with references in DVRs that were suddenly not returned correctly).
Maybe its faster to find a tool to just remove all passwords?
"Are you sure you did Save All and not Save for Previous Version"
- Yes.
"If you want a mass compile..."
- That's what I did and then had to save some of the now recompiled VIs, causing this dialog to show. IIRC LabVIEW sometimes requires a second saving after it has been loaded (or the project has been loaded again), after a recompile (or something like that). This happened when I loaded the project after the mass compile.
@rolfk wrote:
My guess is that you used the new 2024 feature to keep your VIs, libraries or classes at a previous version than 2024 and as that internally invokes the Save for Previous operation for the VIs, it runs into the protection to not save password protected VIs to an earlier version without having you provide the password.
That is probably about it.
The class has:
And the VIs in the class now have
So, when I mass-compiled, did LabVIEW now do that in 2024Q3 then downsaved the VIs to 23.0? Hope that worked...
I tried saving for previous about six years and it always resulted in code that crashed LabVIEW, so I never tried it since then, but I guess it might have been corrupt VIs from the start (never examined) or save for previous works better now.
(I will probably try to forcefully remove passwords from every old VI that has it.)
@thols wrote:
@rolfk wrote:
My guess is that you used the new 2024 feature to keep your VIs, libraries or classes at a previous version than 2024 and as that internally invokes the Save for Previous operation for the VIs, it runs into the protection to not save password protected VIs to an earlier version without having you provide the password.
That is probably about it.
The class has:
And the VIs in the class now have
So, when I mass-compiled, did LabVIEW now do that in 2024Q3 then downsaved the VIs to 23.0? Hope that worked...
I tried saving for previous about six years and it always resulted in code that crashed LabVIEW, so I never tried it since then, but I guess it might have been corrupt VIs from the start (never examined) or save for previous works better now.
I used Save for Previous very regularly over the years and seldom had problems unless one or more of the VIs were seriously corrupted. Identifying the culprit and removing it from the library or project by replacing it with a newly made or at least some empty dummy always fixed things for me.
