Restore Standard Reports in LabVIEW 2018 and later

[Darren]

At one time, the Report Generation VIs in LabVIEW supported a report type called 'Standard Reports', which would send a report directly to your printer. This functionality was removed in LabVIEW 2018 and later (see the LabVIEW 2018 Upgrade Notes for more information). If you use Standard Reports in your LabVIEW applications, National Instruments recommends that you either (1) update your applications to use another report type (HTML, Word, or Excel), or (2) keep your application in LabVIEW 2017 and previous.

If Standard Reports are a critical part of your application in LabVIEW 2018 and later, you can use the following manual procedure to restore the Standard Reports. Note that this procedure is not officially supported by National Instruments. 

Prerequisites

• This procedure assumes you are using LabVIEW for Windows.
• The following products must be installed:
  • LabVIEW 2018 or later
  • LabVIEW Report Generation Toolkit for Microsoft Office 2018 or later
  • LabVIEW 2017 Run-Time Engine or previous
    • This requirement is due to the fact that the NiReport.dll must be installed in order for Standard Reports to work, and this DLL was removed from Run-Time Engine installer for LabVIEW 2018 and later. Also note that the LabVIEW 2018 and 2019 installers include the LabVIEW 2015 Run-Time Engine, so you may already have this requirement fulfilled.

Procedure for restoring Standard Reports to LabVIEW 2018 and later

1. Since this procedure involves manually copying and deleting core LabVIEW files, ensure that your system is backed up beforehand.
2. Make sure LabVIEW is closed.
3. Delete the following LabVIEW folders:
   • vi.lib\printing
   • vi.lib\Utility\NIReport.llb (this is a folder, not an LLB)
4. Copy the contents of the attached ZIP file to your LabVIEW folder. When prompted, you want to merge folders and replace existing files.
5. Launch LabVIEW.
6. Mass Compile the following LabVIEW folders/LLBs:
   • examples\Report Generation
   • vi.lib\express\express output\ReportBlock.llb
   • vi.lib\printing
   • vi.lib\Utility\NIReport.llb

Since this procedure is not officially supported by National Instruments, please post any questions or comments in the discussion thread below.

[Cepera]

Darren

Thanks a lot for this post! I did not upgrade from LV2017 because I needed "standard report" functionality to be able to generate PDF reports. Now I went through the process that you described with LV2023 Q1 (32-bit), and everything looks good so far. One note on the upgrade process: copying ReportBlock.llb (file) to vi.lib\express\express output\ does not work because it already contains ReportBlock.llb (folder). So instead, I copied ReportBlock.llb file into ReportBlock.llb folder.

I built an application and installer in the usual way, except that in addition to LV2023 runtime, I included LV2017 runtime. Tested on a fresh PC, and everything works fine, including standard report generation (with subsequent "printing" to a PDF).

Again, many thanks!

Sergey

[Darren]

Thanks for the post, Sergey, and I'm glad the procedure worked for you.

For anyone else reading this thread, Sergey brings up a good point. In LabVIEW 2021 SP1 and later, all core LLBs in vi.lib were replaced with folders of the same name. So when following the procedure I outline for restoring Standard Reports, you will need to actually replace the LLB-named folder with the LLB itself. Sergey, it sounds like you didn't quite do that (you placed the .llb file inside the .llb-named folder), but this probably didn't cause you any problems because you're probably not using the Report Express VI.

[Cepera]

Darren, thanks for the clarification. You are right, I don't use Report Express VI; in fact, I seldom use any express VIs.

Sergey

[Cepera]

Darren, one more minor issue:

Background: I have both 32-bit and 64-bit versions of LV2023 Q1 development system installed. I also have both 32-bit and 64-bit LV2017 SP1 runtime engines installed. Currently I am in the process of porting my LV2017 32-bit project to LV2023 Q1 64-bit environment.

When I used your procedure on LV2023 32-bit, everything works fine: no problems, no warnings. All the programs in my project work as expected. Now I am in the process of porting the project from LV2023 32-bit to LV2023 64-bit.

To enable standard reports in LV 2023-64, I used the same procedure that you described - and the same files - as on LV2023-32. Now when I load my VI that uses standard reports, I get several similar warnings for different VIs from vi.lib. Here's one of them:

Load and Save Warning List:

C:\My Project\Source v.2.23-64\AEReportPage.vi (AEReportPage.vi)
LabVIEW: (Hex 0x579) Attempted to read flattened data of a LabVIEW class. The version of the class currently in memory is older than the version of the data. You must find a newer version of the class to load this data. LabVIEW class NI_Standard Report.lvclass supports versions 1.0.0.0 through 1.0.0.0. The flattened data is in version 1.0.0.2. Your control or constant value has been reset to the class default value.

Thinking that maybe something in your ZIP file does not recompile correctly in LV2023-64, I put together a similar collection in LV2017-64 that I have on another computer, and followed your procedure with this collection, but I got the same warnings. (I must say though, that I can ignore the warnings, and everything works correctly, but it would be nice to be able to get rid of them.)

Any idea where they come from and how to get rid of them?

Thanks!

[Darren]

I have not heard of that issue. I wonder if modifying the version number stored in the NI_Standard Report.lvclass could fix the issue. I also wonder if somewhere in the code I posted there is a LabVIEW class constant, control, or indicator with default values stored. I can't imagine any reason that would need to be the case, so if that does end up being the issue, the simple fix would be to just reset that object to have the default class value.

[Cepera]

Darren, thanks for your suggestion. I opened each of the 7 offending VIs; each contained "Generate Report Object Reference.ctl" input on its front panel. Then all I did was I "made current values default". That fixed the problem.

Sergey

[Cepera]

Darren, half a year after I started using your workaround for using standard reports in modern versions of LV, it works fine. A bit of a inconvenience in redeploying the workaround after every LV upgrade, but that is tolerable. I do wish though that NI brought back support for standard reports and added PDF generation as a standard, supported feature.

And speaking of PDF generation, I have a follow-up question for you. For generating PDFs, I use a custom version of Cute PDF Writer that supports specifying default folders and filenames through an awkward API (programmatically specifying key values in the Registry). It also has other problems, so it is not an ideal solution. Meanwhile, Microsoft is now including "Microsoft Print to PDF" printer as a standard feature in Windows, so I would really like to switch to it from my custom Cute PDF. But for that, I would need to call "Print Report.vi" and pass report reference to it, all while being able to (1) specify the target file path and bypass the file dialog completely, and (2) in another scenario, specify the default target file path for the "Save Print Output As" dialog.

Any ideas or suggestions on how to do it?

Thanks a lot,

Sergey

[Darren]

I have also used the 'Microsoft Print to PDF' printer, but I don't know of a way to skip the file prompt. I did some web searching and found a few articles (like on stack overflow) that claimed to be able to do it, but I couldn't get their approaches to work.

The approach I've used successfully is to create a Word report, and call the Save Report to File.vi with a file path with a .pdf extension. This approach will generate a PDF file, but it requires Microsoft Word to be installed.

[Cepera]

I've also tried generating Word reports and saving them as a PDF, but it is not a viable solution for my case:

• In my experience, LV2023 does not work well with my MS Office 365: I need to actually have MS Word open before LV can generate a report.
• I cannot require my clients to have MS Word installed in order to programmatically create PDF reports from my programs.

With all that said, your solution for bringing standard report functionality to modern LV works quite well; it allowed me to move on from LV2017-32 to LV2023-64 as my main development tool, so I am very grateful to you! (But at the same time, I am really peeved that NI dropped support for standard reports!)