RGT Excel Get ActiveX References (LV2021)

[Eric1977]

---

It sounds (to me) that you might be more experienced in Things Excel than I, as you are dealing with Classes (and, I presume, Objects), so I might have some things to learn from you.  Would you be willing to explain what you hope to do (which seems to involve "extending" the RGT, perhaps in ways that would be useful for LabVIEW users to appreciate and incorporate)?

---

Sure.

Within the Workbook Class, there is a property called AutoSaveOn (a Boolean) which I'd like to read. This will let me know if I need to Save the Workbook via the Save Report to File.vi or let Excel handle the saving. I believe Word has it too.

Anyone can easily expose that property by going to the Get ActiveX References.vi and placing a property node on the Block Diagram and wiring the Excel._Workbook class to that property node. Then just click on the Property and find AutoSaveOn. Users can set it, if needed.

In my case the VI generates an error. I did a little digging and I see that the To More Specific Class fails when trying to get the Excel reference?? The comments state that it's unable to cast to a NI Excel Class.

[zou]

> BUT...if I try and add a reference to Excel via the Automation Ref,

> I don't see it unless I explicitly navigate to the Excel executable.

Your Excel ActiveX registry has problem.

Most likely messed up during Excel upgrade.

You can register it again manually under command prompt.

It's like:

> regsvr32 yourExcel.ocx

I don't remember the syntax.  You can google it.

[Eric1977]

Which OCX is it? Google searches come up empty when it pertains to the Type Libraries.

[zou]

Under C:\Windows\assembly, can you find Microsoft.Office.Interop.Excel ?

> regsvr32  *.ocx is for register an ActiveX control.  I forgot how to do that for Excel.

[Bob_Schor]

I don't know about .ocx and all, but searching my C: drive for .ocx files, I find a few of interest:

• Program Files (x86)\MSCOMCTL.ocx
• C:\Windows\SysWOW64\comctl32.ocx
• C:\Windows\SysWOW64\mscomctl.ocx
• C:\Windows\SysWOW64\comdlg32.ocx
• C:\Windows\SysWOW64\sysmon.ocx
• C:\Windows\System32\sysmon.ocx

There were a bunch more, many tied to National Instruments, but these were the ones that looked "more general" to me.

Bob Schor

[Eric1977]

You know, I just thought about this...would Office 365 64-bit cause issues? I think (and I have not looked this up) that the RGT might not be compatible with 64-bit Office with 32-bit LabVIEW.

[zou]

You already shown us that excel works with your version of LabVIEW.

[zou]

Instead of *.ocx, maybe try *.tlb.

[Bob_Schor]

I've always run 32-bit LabVIEW, and for at least a decade have been running 64-bit Windows (7 and 10) on 64-bit Processors (Intel) and when the RGT fails, it is due to a Stupid Programming Error which (usually) is quickly fixed.

Bob Schor

[rolfk]

The normal Office 365 install (usually something called one-click install by Microsoft) tends to corrupt something with the Excel Active X interface registration. It seems to be related to the fact that the older versions all were 32-bit and the newer ones are 64-bit. But that doesn’t mean that you can’t access it from 32-bit LabVIEW since the underlaying DCOM technology in Active X is perfectly able to invoke an Automation Server like Excel out of process and marshal all the calls between those two environments if and only if the Active X component is properly registered. The one-click installer seems to mess that up somehow during an upgrade. Doing a manual reinstall in the Apps & Software Control Panel usually fixes that.