Excel ActiveX version

[Nicolas.P]

I am facing an issue with the report generation toolkit.

My dev PC have a 2016 version of excel.

The client PC have a 2013 version of excel.

Between those two versions, the invoke node “saveas” have changed (among others).

The ActiveX modifications create those kind of trouble :

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019N7CSAU&l=fr-FR

The trouble that I faced is the following: When I run my code compiled (or not) on my PC, I do not have any problem. When this code compiled runs on the client PC, the application crash.

My questions :

Did someone knows if there is a way to compile my code for an old ActiveX version ?

Or am I obliged to compile my code on a computer with a 2013 excel version ?

How my code can handle multiple ActiveX version ?

Note: I can’t upgrade client excel.

[RTSLVU · Accepted solution]

Having ran into similar ActiveX issues (even working with NI support until they threw up their hands saying must be some difference in ActiveX), I abandoned the Report Generation Toolkit long ago.

To read/write Excel files I use the XLR8 addon as it does not require ActiveX or Excel to be installed on the target or dev computer.

[wiebe@CARYA · Accepted solution]

---

@Nicolas.P wrote:

My questions :

Did someone knows if there is a way to compile my code for an old ActiveX version ?

Or am I obliged to compile my code on a computer with a 2013 excel version ?

---

No and yes.

I stopped using Excel AX (and report generation) 15 years ago, before actually starting to use it. All because of this. Back then it was not just the Excel AX version, but different languages where also not compatible.

@Nicolas.P wrote:

How my code can handle multiple ActiveX version ?

---

You can make a dll or packed library on the clients computes once, and then load dll\ppl dynamically.

We now use Open XML (API Reference | Microsoft Docs), which requires a lot of knowledge about the xmlx internals (the Open XML Productivity tool, in the SDK is absolutely recommended) , but at least the AX hell is in the past. This should also work for docx (and pptx)... But new inside knowledge is required. On the up side, this is all very well documented. On the downside, there is a lot, and it's not always easy.

[wftmac]

Hello, pls check the office version both you pc and client pc, x86 or x64.

[rolfk]

LabVIEW ActiveX does use Runtime Binding to an interface (IDispatch), but it uses compile time information about the ActiveX interface how to prepare the data to be passed.to the object.

This makes methods of ActiveX components whose method signature changes between versions inaccessible to LabVIEW if you have a different version installed on your system then what the VI was compiled with. It is unfortunate but dynamic runtime data marshalling is complicated and also a lot more performance costly than when the compiler at compile time can determine the data and simply create the code for the correct marshalling at compile time.

All Microsoft Office ActiveX components tend to change the Save() method signature between versions to add new options.

Could it have been changed in LabVIEW?

-> Yes

Could it have been a selectable method option to have the choice between runtime adoption or performance?

-> Of course

Is there a chance for this to be still added?

-> No, ActiveX is a legacy technology as far as Microsoft is concerned and the only reason that they did not Silverlight it so far, is simply that there is way to much software still somehow depending on it. So NI is not going to invest any more money in ActiveX functionality whatsoever.

[wiebe@CARYA]

Another problem is that the rest of the world solved "interaction with Excel" by making more convenient APIs.

There are a lot of .NET wrappers to interact with Excel or Excel files.

However, in our LabVIEW world a .NET wrapper is only useful if there's an assembly somewhere. Without an assembly, you'd have to make one from that code, and we're not C# programmers...

Some libraries might not be suited to do that at all, for some it could be easy... I'm not a C# programmer (, and have very little interest in becoming one).

There's Microsoft.Office.Interop.Excel.dll, I think it will load (and give you a reference to) an Excel AX object. This easies the problem , but it doesn't sole it completely. It solves the loading of the object, but at some point the API changed.  IIRC, it will work for all Excel versions after a certain version, or after. I'd have to look up the details (it might be another MS .NET class). EDIT: I asked, around the time xlsx was introduced, the interface changed, probably ~Excel 2008.

It also won't really do much good, as this will not fit easily in your existing code base.

[Nicolas.P]

Thanks for all those replies.

Finally, I did try the XLR8 addon. 

This addon works fine for what I need to do on this project.

Nicolas