writing reports in CVI

[Haagen-Dazs]

Hey menchar,

I might suggest trying to do the report the way TestStand does it. If you aren't familiar with TestStand, it's a product we make to handle product testing and result collection, so the procedures it uses are optimized for generating reports dynamically. It does this by generating an HTML or XML document with the results--this makes dynamic generation much faster, because it doesn't have to render anything; rather, it can just insert the new lines in the correct spot in the file. An additional benefit is that these are treated by CVI as text files, so you can directly manipulate them using the familiar text file IO functions, rather than using ActiveX automation. This is the approach I would recommend.

You might also take a look at the CVI Report Generation instrument driver, which provides some functions for generating reports. It might be a potential solution to the problem. Here's a help file on that: http://zone.ni.com/reference/en-XX/help/370051V-01/toolslib/toolslibreport_generation_control/

I hope this helps, and let us know if you have any further questions!

[RobertoBozzolo]

Hi Patrick,

unfortunately NIReport is missing some basic capabilities like preview and according to Luis opinion is not subject to further development so at present it does not constitue the best approach to reporting in CVI. 

Office integration implies you have a full Office license (not a Starter one) spent on the machine the CVI program is running on, but some customers are not likely to invest on this, especially on machines dedicated to unassisted, long-running tests or to end-of-line compliance tests.

I have tested several solutions in my life: PrintPanel, HiQ integration (do you remember that obsoleted NI product?), Office integration, creating PDFs with HARU library... all of them with its own pros and cons.

The real thing is that good reporting is becoming more and more necessary for developers of technical applications and at present we are not so well supported by CVI as we are in writing the "operative" portion of the code.

[menchar]

Roberto's pretty much summed it up.

A poorly rendered report can make an entire software package appear amateurish.  Nowadays, it seems everyone's an expert when it comes to reports and GUI's.

We are able to create professional looking reports using Word, but it can be very painful figuring out how to do things, and as Roberto points out, it requires a full Word license on the target.   We find ourselves spending huge amounts of developer time trying to do apparently simple things.  I understand why NI isn't enthusiastic about fine tuning / maintaining the Word automation interface to CVI, the Micro$oft Office group is a world unto itself.

We've tried pdf, but ran into problems with rendering plots - seems pdf is better at straight lines

Sounds like nothing much has changed.

[RobertoBozzolo]

Hello menchar,

I normally don't have images to add to reports, but I often need to add diagrams to them. In this cases I normally have an on-screen diagram that the user has tailored to his needs and wants to add to the report, so I just create a hidden duplicate of the panel or control, customize it for printing (e.g. set a white background and so on), take the image of it with GetPanelDisplayBitmap and move it to the report.

Now, 72 DPI standard PDF resolution is enough for technical diagrams but is really poor for pictures. You may want to experiment creating documents with 300 or 600 DPI: it will make printing notably slower but better in aspect. It depends on what's your goal with the report you are creating.

[Daniel-E]

menchar and Roberto,

I understand the issues inherent with using Office and some of the other methods, and definitely understand the desire to create professional reports. It seems that part of the issue stems from the necessity to re-render the report after each piece of data is added. Would it be possible to instead collect all of the results in a data structure in memory, and then write the report one time at the end? 

The downsides to this approach are that it uses more RAM and does not allow you to view the report during execution, but it might end up being faster since the report won't need to be rendered more than once.

[menchar]

We do that.  The problem isn't the fact that if you do things improperly that Word is very slow, the problem is that it's so hard to figure out how to work around it. 

One way NI might add value to the Word Automation interface in CVI might be to simply have a sample report available that's been created from CVI that demonstrates various tables, forms, graphs, plots, etc. and also the code that created it.  A good project for a new hire, that lets them figure out how to do things in CVI as well as creating a useful example for the user community

[menchar]

Roberto -

Thanks for the ideas.  I'm not the one who tried the pdf reports.  We do a lot of images (greyscales), histograms, XY plots, column charts, etc. and somehow it became apparent that pdf wasn't doing the job.  The developer involved is very experienced:  I suspect he had a good reason for giving up on pdf.  He was using a pdf add-in to Word, as I recall - maybe he was hitting some limitation there.

We've had real problems with pasting bitmaps into Word.  I think most of our problems tend to be associated with the sheer size of some of our reports and images - things that generally work in the small break when we do them a lot.

Menchar

[mukesh121]

Use Virtual printer (PDF creator , cute PDF write............e.t.c)