Error while saving excel report on target PC (Access violation 0x0000005)

[JacobSzlaur]

Well this is unfortunate ...
Thanks for all the advice!

Just one last thing (probably not the best place to ask):
You said this is also problem in other programming languages (you specified C++).
I was wondering if this also affects Python? Because I'm wondering if I shouldn't just switch to it if it can handle Excel better.

[rolfk]

Python is not compiled. Not sure about there specific implememtation to call ActiveX methods but there is a good chance that it can deal with changing APIs if it resolves the parameters against the typelibrary at runtime.

It actually seems that most Excel for Python extensions don't use Excel at all.

[JacobSzlaur]

Okey, one last question:
I'm looking now for alternative way to somehow save the data and graphs ... One way could be just saving the RAW data to .txt file / .csv and then separately save .jpg of the Graphs on the front panel. But this would require the costumer to manually add it to the Word / Excel.

So I though about printing everything to PDF?

Would this solve my problem? Would I be able to print and save the PDF without any problems with inaccurate versions? Because when I looked here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kGF9SAM&l=cs-CZ 
This code clearly takes advantage of save report vi ... Am I able to print the PDF without saving it first somewhere?

[rolfk]

The licensed Report Generation Toolkit has 4 possible options to print a report: Standard, which uses an NI ActiveX component that can also be send to the printer, HTML, which stores it as HTML document and Word and Excel. The latter two use ActiveX and therefore have the problem about interfacing to different versions of these office apps. Standard is not very future proof as NI has stopped developing the underlaying ActiveX component and it won't work in 64-bit LabVIEW. HTML is the most versatile but doesn't povide you a single container document.

If you can live with that then I think HTML is the best solution.

My approach is usually slightly different. I use csv whenever possible and make it clear to customers that this while not necessarily the most integrated approach is the best in terms of future proofness. Text files will be always readable as long as they aren't badly corrupted but for other formats even minor corruptions can already be fatal.

If a customer really insists on graphical reports I use the Carya PDF Toolkit to build it myself. While the price of the Toolkit is pretty cheap the extra work needed to build such a report is substantial and you should never underestimate it. In theory you can put together a report in a few hours with a graph and various text elements and a logo. In practise the customer will want to have many cosmetic modifications to the report after the initial proposal and that will take up lots and lots of time to get right. Usually if you account for all this extra time in a quote most customers find suddenly the csv approach very attractive.

[mcduff]

Their defence will be: Don't use a compiled programming environment. Everybody nowadays uses .Net and should not use ActiveX anymore.

Please excuse my stupidity/ignorance here. I don't use the Report Generation Toolkit, and rarely ever try to use an Excel sheet, unless it is specifically requested.

When I do use Excel, I use .NET calls within LabVIEW to Excel. For a compiled program, is this safe for future versions, or like ActiveX, where I will need to update for every possible configuration? I know that Excel needs to be on the target computer with .NET, just don't know whether I have to give a specific version with instructions to never update.

Thanks

mcduff

PS Sorry for hijacking the thread.

[JacobSzlaur]

Wow cool!
Could you please redirect me to somewhere where I can learn more about .NET in LabVIEW? If you say that using .NET functions would solve the problem with unmatching versions I would really like to look into it!