MS Office Dynamic ActiveX Reference

[SEAG_ROWI]

Hello everyone,

I’m using LabVIEW ActiveX to access a MS Word document. In the Development environment it works. But every time there is an Office 365 update the built application brakes. In LabVIEW whenever there is an Office 365 update it prompts me to save changes made to the VI that opens the ActiveX reference even if I never touched it.

This is how I configured the reference to ‘Word._Application’:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KZNSA2&l

is there a way to do this at runtime? So that the Reference passed to the open Automation VI is not a constant?

Or is there some other fix to this problem?

[rolfk · Accepted solution]

The way LabVIEW interfaces to ActiveX components is unfortunately semi dynamic. It does use the Dynamic Dispatch interface but also uses UID and method identifiers for the various APIs directly compiled into the binary rather than trying to lookup those IDs at runtime. Supposedly this is for runtime performance and more likely how ActiveX was used back then around 2000. An ActiveX interface was supposedly maintaining the ID numbers between versions unless there was a breaking change and then it would increase those IDs. Microsoft is actively trying to get away from ActiveX as much as possible in favor of "everything .Net" but has to provide ActiveX support for backwards compatibility. That does not mean that they have to adhere to the rules as they were valid back then and likely for ease of version management simply keep changing the according GUIDs with every new release.

Unfortunately the LabVIEW ActiveX functionality was implemented back in the 90ies of last century and since about 15 years is considered legacy technology even by Microsoft itself. Therefore chances that NI is going to spend much if any effort in this area is virtually below 0. If I had access to the LabVIEW source code it would likely be a relatively simple change to allow the option of interfacing to the ActiveX APIs fully dynamically also at runtime. But it would be more than a simple change for sure as it would require some extra selection option for ActiveX property and method nodes, and also some additional information in the stored binary structure of compiled VIs to reference to the Class, Method and Properties by name instead of IDs.

[Yamaeda · Accepted solution]

I guess it shouldn't be too hard to remake it at .NET (as it should be). This quick attempt didn't quite work though.

[SEAG_ROWI]

Thank you everyone for the good replies. I will explore the option of calling the .NET framework. It looks like you need to install Visual Studio to access the ‘Microsoft.Office.Interop.Word.dll’. Unfortunately, I don’t have time to explore the solution right now.

[Yamaeda]

I don't have Visual Studio. I do have Office though.

[DavidBoyd]

You may find the info in this prior thread helpful as well, if you're considering staying with ActiveX and the Report Generation Toolkit.

Dave