Windows 11 vs RGT (Report Generation Toolkit)

[Bob_Schor]

I'm attempting to migrate a LabVIEW application originally developed with LabVIEW 2021 SP1 (32-bit) running on Windows 10 (64-bit) to a new PC running Windows 11 (it came with Win 11 pre-installed, making the IT Guys happy).

One "feature" is that I save the data during the test as a Delimited Spreadsheet (fairly low data rate, a few Hz), and at the end, provide both the "raw Text" and a nice Excel Workbook which is much easier on the eyes.  I'm building this as an Executable, and transferring it to the User's PC on which I have loaded an appropriate LabVIEW Run-Time System.

First problem -- couldn't get the code to run on the Windows 11 machine.  Looked up compatibility tables, looks like LabVIEW 2021 SP1 is not Windows-11 compatible (and I couldn't get it to run -- surprise!).  OK, time to abandon "older" versions of LabVIEW and migrate to, say, LabVIEW 2024 Q3 (and maybe move to 64-bit at the same time).

Took a test machine with Windows 10, LabVIEW 2019 SP1 (32-bit), LabVIEW 2021 (32-bit) and LabVIEW 2024 (32-bit) (this latter used only to provide some support for the LabVIEW Forums), remove all NI Software, and reinstall LabVIEW 2021 SP1 (32-bit) [for compatibility with existing VIs] and LabVIEW 2024 Q3 (64-bit), "moving forward".

Of course, I installed "most recent first" (as I learned "the hard way" with LabVIEW 2018).  Once the dust settled, I tried to build and run my application using LabVIEW 2021 SP1 (32-bit).  It almost worked (on this Windows 10 machine), except for the usual failures with the RGT due to discrepancies in the options for some Invoke Nodes. an easy fix once you find them.

So on to the Big Test -- will my code work on a Windows 11 PC with a LabVIEW 2024 Q3 Runtime installed.  Of course, I have to fix the RGT functions, just as I did in the preceding paragraph.  I can fix them just fine, but I cannot save the Results!.  Although I'm running LabVIEW 2024 using an Admin account (because it lives in "Program Files"), I get the following message:

Note that I did not have this problem when I was patching the similar RGT links, which were located in Program Files (x86) (because that was supporting 32-bit LabVIEW).  Also note that the VI is inside an .llb -- I can copy it out to my desktop as a stand-alone VI and modify it, but I haven't (yet) figured out how to stuff it back in to the .llb (or wherever it is stored).

Did a brief Web search, but probably asked the wrong Question, so I came here ...

Bob Schor

[Darren · Accepted solution]

This issue has already been reported to LabVIEW R&D as Bug 2702314. According to R&D it will be fixed in the next LabVIEW release. For now, here's the workaround (assuming you have admin privileges on the machine):

1. Set the file permission of any affected VIs (like Excel Sort Data.vi in your situation) to writeable.
2. Launch LabVIEW as Administrator.
3. Relink the method in the VI.
4. Save the VI.
5. Change the file permission back to read-only.

[Bob_Schor]

Thanks, Darren, and I'm glad it is being fixed.

At about the time you posted, I was in the process of tracking down the few (3 or 4, perhaps) VIs that had the "relink" problem with Excel.  If these files are all in "Admin-only" space (e.g. in C:\Program Files, where you need to be an Admin to mess with them), why make them Read-Only?  This was also the first time I encountered a tri-valent Read Only state (unchecked, R/W, Checked, R/O, and "black square", what I'll call "Propagating R/O" which passes the setting "down the chain" of Files and Folders).

My best wishes to all my NI and LabVIEW colleagues for a peaceful and fulfilling New Year.

Bob Schor

[Darren]

---

@Bob_Schor wrote:

If these files are all in "Admin-only" space (e.g. in C:\Program Files, where you need to be an Admin to mess with them), why make them Read-Only? 

---

My understanding is that the assignment of admin-only privileges to the LVAddons folder is because, as a general rule, NI R&D doesn't want core LabVIEW files to be edited (either accidentally or intentionally). If you're running LabVIEW as Administrator (which a lot of developers do), you could still edit files if they weren't read-only. To edit files with the current setup (which you had to do in this case because of a bug), you have to jump through multiple hoops, which is kind of the idea.

[Bob_Schor]

Thank you, Darren, for the "common-sense" explanation for the extra "protection" NI puts on its software ifolders and files.  It took me a while to grasp the importance of a separate Admin account (to save me from myself!).  The "common-sense" method to "update" the links that NI provides to non-NI software (like the Report Generation Toolkit!) makes perfect sense.  Until now, I had not installed anything newer than LabVIEW 2021, and the RGT locations weren't as securely "protected", but now I'll recognize how to make the "healing" modifications by temporarily removing the "Read-Only" status to the VIs that (as they say in Pittsburgh" "needs patched".

Bob Schor