10-18-2012 01:38 AM
I currently use the LabVIEW Report Generation toolkit in LabVIEW 2011SP1 to create simple spreadsheet reports that I can build/print without having Microsoft Office products installed. I really like being able to do this, and it allows me to generate nice on-demand data reports - I'm also not tied to having Office installed on the system I'm using, so this works on just about any test fixture I can install the software on.
I recently have a requirement that I must have variable-length columns in my report. I currently use the VI "Append Text Table to Report" in order to create a text table, but the column width requirement is that all columns must be equal width UNLESS I use an Excel Template file to define my column widths.
My questions are:
10-18-2012 07:47 AM
Are these real Excel files or are they *.csv files that open in Excel?
10-18-2012 02:48 PM
What, the template file? The template file is actually an MS Excel file, as a .CSV does not contain formatting information (only data). The Report Generation Toolkit uses the column width information properties in the spreadsheet in order to get the information it needs. However, I don't know if MS Excel is required to be installed in order to determine those properties, or if the toolkit actually knows how to interpret an XLS file format to get that info - my guess would be that it needs MS Excel and uses ActiveX to get the info it needs from Excel. If my gess is correct, that's not an acceptable solution for what I want.
10-19-2012 03:37 PM
Can you provide a screenshot of your code? I am having a hard time understanding what it is you are doing / trying to do. What type of files are created when you run this code without excel?
10-19-2012 04:40 PM - edited 10-19-2012 04:56 PM
Sure, I'll provide a pared down example that demonstrates my use-case:
I have a control to the VI that takes in a 2D array of strings representing the data I want printed in a table. I am generating a standard report, adding a table to the report, and printing it. The first VI is "New Report.vi", the second VI is "Append Table to Report.vi", and the third is "Print Report.vi", all found standard in the Report Generation palette.
Note that the "Append Table to Report.vi" has an input parameter "Column Width" with a default value of (1). This input parameter is a single input parameter, which defines the column widths of ALL the columns in my table - hence, with the VI the way it is, all my columns will be 1 inch wide.
I find myself needing to be able to define per-column widths, not just a single global column width parameter.
The only way I have found to do this is by using an Excel template file. The "New Report.vi" takes in a "template" parameter, and if used, the report generation toolkit can be set to ignore the "Column Width" input parameter on the "Append Table to Report.vi" by setting the width value to -1. Instead it will launch Excel, open the template file provided, build the table using the template, will close Excel, and will attach the generated table to the report. However, I have a strict requirement that Microsoft Office NOT be required to be installed on the computer.
So, without using Excel, is there a way to generate a table in a report and define the width of each column individually?
10-22-2012 04:57 PM
Thank you for the code snippet, I have looked into your question a bit more.
The short answer: No, I do not think there is a way to generate a table in a report and define the width of each column individually without using ActiveX with Excel.
The long (and not officially supported) answer: If you double click the Append Table to Report.vi icon in your block diagram, you can follow the column width input deeper and deeper into the toolkit arrays. Keep double clicking on the subVIs that Column Width is tied to until you find a block diagram that looks like this:
Hypothetically, if Column Width here was an array auto-indexed to the for loop, you could set per-column widths as long as the array size matched up with Number of Columns. HOWEVER, I cannot vouch for certain if this would work properly and if you overwrite the original VIs, you could really mess up your toolkit functions. Only jump into these if you are very confident in what you are doing.