LabVIEW Idea Exchange

Currently I use LabView through a Windows VirtualBox on a Linux Mint machine. I was told by a customer support employee that I should bring this idea to this forum. I chose this method because of the limited support for Linux even with the supported distro discs. I encourage NI to expand their Linux-compatible software to have the full capabilities that the Windows and Mac versions do for the distros that are currently out, and to expand the number of distros supported. Linux Mint is one of the most widely used flavors, and yet there is no support from NI.

If NI were to make the following modification to the Word_Save_Document vi, we would be able to generate PDF documents directly out of the Report Generation Toolkit. This may only be applicable to later versions of Word.

What is required is to handle the PDF file extension and set the appropriate wdSaveFormat value for the SaveAs Method. It would also be nice to be able control the show PDF after generation option, but just being able to save as PDF would be very useful.

It would be nice that if a VI documentation set is created into HTML with PNG as picture format a snippet option would be included.

This option would embed a VI snippet of the top-level BD inside the PNG instead of a static image.

This way it's possible to distribute the code inisde the documentation.

If an XControl is placed inside user.lib this XControl is not added to the palette.

This means that if you distribute an xcontrol you need to send a mnu file with the xcontrol which adds another folder inside the user.lib palette.

I think that an Xcontrol should be indexed like standard controls.

My request is very much similar to Rob Hingle's request posted in "Need custom column widths in Append Text Table to Report" thread here:

http://forums.ni.com/t5/LabVIEW/Need-custom-column-widths-in-Append-Text-Table-to-Report/td-p/1108404

I discovered the above thread while looking for a solution and I got very disappointed that the discussion in that thread did not lead anywhere...

Rob actually said it all; I can only second him here as my problem is basically the same. Nevertheless, I'm putting it out here for reader's convenience.

In my practice, I often need to create a LabVIEW standard report (for printing on paper) which would contain, among other things, one or more tables. The tables must have columns of different width. Some columns need to be just a few characters wide, while some other columns have to be quite wide. For example, a table of chemical compounds would contain a Sequential number and a Compound ID, and a few other columns. The first column needs to be three characters wide maximum, while the Compound ID has to be much wider (say, 30 characters wide). There is no way I can use the standard LabVIEW "Append Table To Report.vi", since it sets all the table columns to be of equal width. In the past (LabVIEW 7) I was able to do this by modifying the "Append Table To Report.vi" and its subVIs so that the VI would take an array of column widths instead of a single scalar value. It became quite difficult to achieve since NI reworked the Report Generation Toolkit... I ended up importing and using the old toolkit - now with LabVIEW 2010 and 2011, which is obviously not the best solution.

I'm surprised that this issue apparently did not draw more attention so far, since IMHO it's been a glaring deficiency of the Report Generation Toolkit for some time now. Why the Report Generation Toolkit was designed with the assumption that columns in tables can only be of equal width is just beyond my understanding... Generating printed reports with tables is a quite common task, and most of real-world tables have columns of different width - just take a look at a few tables in books, magazines, manuals... A table with columns of equal length is quite a special case of more generic form, and can be easily obtained if needed by specifying the same width for all columns in the table.

Please make the "column width" input of the "NI_report.lvclass:Append Table to Report.vi" an array... To provide backwards compatibility, the VI can be made polymorphic (I hope), so that either an array or a scalar could be used.