LabVIEW Report Generation Toolkit for Microsoft Office runtime consistency check

[michele.santucci]

Hallo,

I'm going to deploy on a large number of different PCs a test application made by LabView 2013 and using Report Generation Toolkit for Microsoft Office, the application will run compiled.

In the last months I learned that the only chance for this application to run smoothly is to work into an environment much like that where is been compiled (Office version/bitness, runtime version etc).

Unluckly is hard to predict which version of Office is installed in each of these PCs and it's also difficult to predict a not working behaviour because sometimes it simply doesn't create the report, some other time it just crashes the application.

I can build the application on different workstation to offer a broader range of setup to use but this doesn't fix the problem of failure detection.

My question is:

 How can I check if the Office version installed on the target machine is the same as the one the application binary have been compiled with?

Best regards,

 Mike

[aeastet]

If you need to work with different version of Excel I would look into OpenPyXL. It is python code the is open source that you can tap into using LabVIEW to open and save excel files. It also does not required MS Office to be installed in order to work. We have started looking into switching out all of our active X and .net features to this library to remove the Office requirement. 

https://openpyxl.readthedocs.io/en/stable/

We have built an interface to this python code inside of LabVIEW that allows us to do what we want. You could do the same thing. It would also make it so the version of Office does not matter any more:

[Bob_Schor]

If you look in the LabVIEW Tools Network (which you can open with the VI Package Manager that should have been installed when you installed LabVIEW), you can find the "Viewpoint Xlsx Toolkit for LabVIEW" which (a) doesn't need Microsoft Excel to be installed, and (b) might have all the capability you require.  There may be a license fee, but it has a free "Evaluation" period.  Other packages might also be available ...

Bob Schor

[rolfk]

While the Python library could be a feasible option it comes with its own trouble.

- LabVIEW 2019 or newer only, 2023Q1 if you use a Python installation with virtual environments

- The LabVIEW side specifies the version to use, if that isn’t installed it won’t work.

- Python bitness must match the LabVIEW bitness

- According Python library must be installed into the right Python installation and if applicable virtual environment.

A lot of prerequisites that simply makes large deployment not easier but rather more complicated. It’s fine if you can control all the machines your application is deployed too but otherwise just makes things only worse. The mentioned Toolkits may be a better solution depending on your requirements, except if cheap trumps your requirements.

[michele.santucci]

Just a followup since I see you're providing me options I simply cannot apply.

I cannot change the tools I'm working with: I need to keep on working with LV 2013 32 bit, Office 365 32bit, and NI Report Generation Toolkit for Microsoft Office.

At this time I cannot upgrade the LV license, neither use dfferent toolkits of any kind (even if they were free or opensource).

[Bob_Schor]

---

@michele.santucci wrote:

My question is:

 How can I check if the Office version installed on the target machine is the same as the one the application binary have been compiled with?

---

Our apologies -- you did clearly state your question in your original post.

Here is the answer directly from Microsoft Support to "What version of Office am I using?"  (click on this link).

Bob Schor

[rolfk]

The way I solved this in the past was to create a wrapper Vi that then dynamically calls the right subVI for the version needed. This gets a real pain in the ass to develop and especially maintain as you need a LabVIEW installation with according Office installation for every Office version you want to support. Usually it only affects a few actual functions such as the Save method since Microsoft keeps overloading that with a new method with more optional parameters. And the LabVIEW ActiveX interface is compiled to a specific version and does not support methods with varying optional parameters at runtime. While ActiveX IDispatch would support that choice at runtime, LabVIEW strictly preconfigurs the runtime setup for that IDispatch call at compile time and does not allow for runtime adaption. It would have been relatively easy to support such dynamic adaption in the ActiveX IDispatch interface with a small change in the compiled VI format that also stores the Method or Property name instead of just the DispatchID but ActiveX being declared legacy technology by Microsoft for many many years makes such a change from NI as likely as the hell going to freeze over.

How to detect which dynamic version to call could be either by trial and error, load each version and if load was successful without error try to call it until you find one that succeeds, or try to find an Office ActiveX method or property that tells you the actually installed version. I chose the trial and error method back then and swore to never again promise a customer to support that unless he is willing to promise me a golden palace in the Himalaya!

[michele.santucci]

I absolutely agree with you on the need to find a different tool to achieve this result (if you look into my profile you can see I already asked for this kind of solution in the recent past), there's no golden palace promise that will convice me to use again an ActiveX based tool.

I'm also trying to write a .Net backed and related LabView wrapper to provide an one-on-one alternative on the report toolkit (of course based on OpenXML SDK), but this will takes much time and I need to manage the current situation with the tools I got.

[rolfk]

The .Net interface to Microsoft Office is mostly just a hack. Under the hood it is nothing more than a COM Interop wrapper around the ActiveX interface. It may or may not circumvent this particular problem but overall you end up with this:

I had a problem calling an ActiveX interface and choose to call the .Net wrapper around that ActiveX interface instead. Now I have at least two problems!

The advantage and at the same time a big drawback is that the .Net Interop wrapper is an almost 1:1 mapping of methods and properties to the ActiveX interface. Quite easy to rewrite if you have the ActiveX code available. At the same time it misses many opportunities to remake the somewhat archaic object interface and adds an extra redirection with an extra and different memory management paradigm to the bigger architectural complexity.

[joshua.l.guthrie2.civ]

Can you roll your own? 

I'm in the process of pulling out the report generation tool kit from all my code for many of the reasons you talk about.  It's temperamental, and SLOW as all get out.

The attached is very much a draft attempt and no where near finished.  use for inspiration (even if what not to do).

I'm very much interested in what you come up with.