NI-supported Direct to PDF Report LV Toolkit

[battler.]

Direct to PDF reporting is an extremely important feature to provide customers.  It cannot be relied upon that the customer has MS Word or the like installed.

There are a couple of LV PDF toolkits supplied by developers.  However, the problems with these include that they are (a) not updated or well-supported (b) buggy (c) have out-dated dependencies such as .Net 2.0 (d) restrictive licencing for deployment.

Good reporting tools are essential and NI should develop and support a direct to PDF toolkit.

[Darren]

Duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Generating-PDF-protocolls-with-the-Report-Generation-T...

[elset191]

I'm not sure how relevant this is, but there's a method for the Excel Workbook called ExportAsFixedFormat that allows you to export as PDF.

I used it on some legacy code that basically does what the Report Generation Toolkit does.  I haven't poked around much, but it doesn't seem the the NI_Excel.lvclass is easily extendible to add a method around this.  Also I don't think you can get the workbook reference out of the class.  It seems you can edit the subVIs but not the classes themselves, which isn't terribly useful unless you don't mind breaking some existing functionality.

Of course in this way you'd have to build an Excel file instead of going straight to PDF, but may be a viable workaround.

[AristosQueue (NI)]

elset191: We've talked about doing that and it might happen the next time the RGen toolkit get rev'd. But the idea specifically mentioned not requiring the customer to have additional tools installed. That would means us building up our own code for PDF construction.

[wiebe@CARYA]

Hi Battler,

I'm not sure what catagory our PDF Toolkit (www.carya.nl) falls in:

(a) not updated or well-supported

(b) buggy

(c) have out-dated dependencies such as .Net 2.0

(d) restrictive licencing for deployment.

The free version isn't updated, but we have active development on it (mostly to include CJKv fonts). No .NET dependancies (only zlib, but we use a windows .net function for compression on 64 bit systems). It is used on Linux and MacOS as well. Hopefully it's not buggy, although the V1 has known bugs. We don't feel the deployment licencing is restrictive.

There is an example that adds a graph as vector image. It's very hard to make a general interface to draw graphs, so for now it's just an example. Ideally (perhaps in a new toolkit version) there well be an OOP framework to add vector graphs without too much programming.

AristosQueue:

The new release of our toolkit will have a fully functional free version. We've been thinking about a RGen pluging. Since it's OO, it doesn't seem that difficult. The only think stopping us from doing it is time, and the RGen enum that doesn't have a PDF or 'other' option. It's really wierd how that has been done by NI, and it makes the OOP implementation somewhat useless. If someone wants to make there own child, he'd have to hack around thgis enum at least to get some of the main VI's working.

Regards,

Wiebe.

[AristosQueue (NI)]

> It's really wierd how that has been done by NI, and it makes the OOP implementation somewhat useless.

LabVIEW users outside of NI weren't the only ones learning a new paradigm when LabVIEW classes were introduced.

[wiebe@CARYA]

>> It's really wierd how that has been done by NI, and it makes the OOP implementation somewhat useless.

>LabVIEW users outside of NI weren't the only ones learning a new paradigm when LabVIEW classes were introduced.

I understand. I've just started OOP, and there is a lot to learn.

It would be easy to fix though, by giving the enum a "other" entry, and a "other" class input that is only used when "other" is selected. That won't break existing code, and is easy to implement.

[wiebe@CARYA]

>> It's really wierd how that has been done by NI, and it makes the OOP implementation somewhat useless.

>LabVIEW users outside of NI weren't the only ones learning a new paradigm when LabVIEW classes were introduced.

I understand. I've just started OOP, and there is a lot to learn.

It would be easy to fix though, by giving the enum a "other" entry, and a "other" class input that is only used when "other" is selected. That won't break existing code, and is easy to implement.

[mbaudot]

Word is able to save documents as PDF since many versions now. NI could just modify the VI Word_Save_Document.vi as shown below to enable this feature.

There is less than 20 values possible for the Word SaveAs method (http://msdn.microsoft.com/en-us/library/bb238158%28v=office.12%29.aspx) and for some reason, NI just added 5 of them in the case structure. Lazy, or is there some reason why it's not done ???

Unfortunately, the class is protected and for now you have to modify the original VI on the disk :S

If NI was willing to give us a public accessor for the Document Ref (at least), it would be really great too!

[Darren]

I describe making this change in the following Darren's Occasional Nugget:

http://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-05-13-2014/m-p/2847152

We are looking into making the change official in a future version of the Report Generation Toolkit (RGT).

To access the ActiveX references of your report (in order to make your own custom subVIs to use alongside the RGT), you can call the following toolkit VI:

vi.lib\addons\_office\word.llb\Word Get ActiveX References.vi