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

[JacobSzlaur]

Hi everyone,

Specification on what I’m using:
Development PC:

• Excel 365
• LabView 2016, 32-bit version
• Windows 10, 64-bit

Target PC:

• Excel 2010
• LabViewRTE 2016 (don’t know how to find out what version i tis)
• Windows 10 Pro, 64-bit version

What have I done so far to repair the problem:

I started using report generation toolkit just few days ago. I had some issues with even building the VI on the first place – so many broken arrows in sub VI’s. Here is what I have done and what I have investigated:
1) https://forums.ni.com/t5/LabVIEW/Error-Saving-File-with-MS-Office-Report-Express-VI/td-p/3935752

2) https://forums.ni.com/t5/LabVIEW/Save-Report-to-File-Report-Generation-Toolkit-isn-t-actually/m-p/38...

3) https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019N7CSAU&l=cs-CZ

4) https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019ZVkSAM&l=cs-CZ

- Tried both .xls and .xlsx type of files. None of them work.
- Changed also password input to writerespassword in Save report VI

Because of these threads I’m able to run the main VI without any problems on my development PC. Report is generated, then it is saved and closed – just as I want it to work.

What is the problem:

Now, when I build the executable application from the working VI everything again work just fine on my development PC, but when I run it on target device some weird things happen.
The report is generated, then I can see how the data is being inserted into the report, but when the VI tries to SAVE the report (not close!) the whole application crashes.
How I know it crashes when SAVING and not closing? The report doesn’t close and it’s not disposed of.

ALSO maybe important:
First few times it crashed the app throwed error: “Access violation 0x0000005”, which doesn’t make any sense because I start the app as administrator + I create the directory where I want to save the file in the app.

I’m truly lost on this one! Have no idea what else I could do.
Thanks in advance for all the suggestions!

[PalanivelThiruvenkadam]

In Development Environment when you are Invoking MS Excel DLL of a Computer with Excel Version and when you use the same code in another computer with Different MS Excel Version then it will expect for re-linking of  the function.

I haven't experienced the issue in Executable.

[JacobSzlaur]

So your suggestion is that I need to re-link the function again?
How should I re-link the function?

If you mean pressing right button and pressing "Re-link" I have already done that and there is no longer option "Re-link":

[PalanivelThiruvenkadam]

This will be required for the first instance whenever there is a change in excel version.

Check whether both you PC's are having Same Excel.

[JacobSzlaur]

"This will be required for the first instance whenever there is a change in excel version."

For the first instance of what? And what will be required? Re-linking the VI?
I'm sorry I don't know what are you talking about.

"Check whether both you PC's are having Same Excel."

No - target PC have 2010 version and development PC has Office 365.

[rolfk]

Access Violation has absolutely nothing to do with how you log on your system. That is an exception generated by the CPU itself when it tries to access an invalid memory address.

And the problem is the Excel Save method which has been extended by Microsoft with almost every new Excel version to have even more optional parameters and to add them not always to the end but somewhere in between. Your LabVIEW code compiled to interface to the Office 365 version of Excel (internal version usually 16) fails catastrophally when trying to invoke the Excel 2010 method which has a different parameter signature.

For most other ActiveX interfaces this has never been an issue since developers don’t change the interface of an API like that usually. The Microsoft Office developers however didn’t expect their APIs to be called by compiled programs who don’t resolve the API call on each new call again like Visual Basic does. Only solution is to build your LabVIEW executable against the Office version you want to have it finally run.

This is not a LabVIEW specific issue but happens with other compiled programming languages like C++ too when trying to call these ActiveX methods.

[JacobSzlaur]

So the solution will be to build the executable on a dev. PC that have the same Excel version as the target PC if I get you correctly?

[rolfk]

Yes!

[JacobSzlaur]

Wait ...
So if I want to have application that I will sell to multiple customers (and I don't have any control or idea of what excel version they are using) I have to build each executable specially for them? Depending on what Excel they are using? 

+ I have to have on my development PC multiple versions of Excel? And every time activate one of them? Or uninstall rest and install the one I want to use?

Isn't that weird? Are there any other ways?

I just can't imagine how that should work.

PS.:
Does this apply to Word too? Or is it Excel specific?

[rolfk]

Yes and yes. Microsoft in their infinite wisdom decided to make such modifications to both Word and Excel methods between some versions. Of course that is the same company whose CEO was quoted to say who will ever need more than 640 kB of memory in a computer. 🙂

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