LabVIEW
Built in Excel Broken Vi's
@DavidBoyd wrote:
I'm grateful that you have that detailed level of understanding of how LabVIEW calls ActiveX; I wasn't aware of the details of MethodName => MethodID => IDispatch. I'm fairly certain that a few years ago,I was able to "fix" broken linkage (where a VI loaded broken because of an added parameter), by the conditional compilation trick, but perhaps I was fooling myself.
It may have worked but the Conditional Compile Structure is likely not what you used. Conditional Compile selects the code to compile based on a definition that would not change because there is a different ActiveX version present. Instead you may have used the Type Specialization Structure. This one disregards frames that give a compilation error so your bad ActiveX Node would be ignored and the good one gets chosen. Still this will not work in compiled code as the Type Specialization Structure needs to be reevaluated and recompiled for this to work.
I suppose in an ideal world there would be a complete RGT rewrite by now, assuming that everything needed to interact with Word and Excel was available via .NET, but I suppose that's a fever dream. A little more delirium would include having compatibility to "drop in" the new release directly in place of the old.
But then, I'd have much more use of a .NET-based refresh of the Database Connectivity Toolkit, so that might be my first fever dream 🙂
Yes of course, recreating everything would be ideal, except of course who would do that?
I haven't used it myself, but I have heard good things about the "XLR8" toolkit:
https://dataahead.de/en/xlr8-labview-toolkit-2/
As I understand, it doesn't use ActiveX, but NPOI, which uses .NET to access Excel.
@spforster wrote:
Hi David,
I've managed to fix this issue with the particular Vi that I posted about in this thread, using details that you posted on a previous thread regarding the registry files for excel, as I'm using a 64-bit Office 365 and 32-bit Labview. I found that I had some extra stuff in my registry file under [HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}] that I didn't have on the other computer. Removing the extra stuff seems to have made it work, however I still get issues surround other Vi's relating to Office report generation. I'm guess there is still some mismatching between the 64-bit Office and the 32-bit Labview. Would there be other registry files that need looking at apart from the on named above?
That's another problem, that NI is not responsible for. Basically ActiveX is a very complex technology that allows in-process and out-of-process invocation of ActiveX servers. But the component needs to be registered correctly to allow that. Most ActiveX components are invoked in-process since that is direct and a lot more performant. Out-of-process invocation works by invoking the component in a proxy process that then marshals all the parameters back and forth through interapplication communication, usually pipes if on the same computer, TCP/IP if on a different computer.
If the component is not the same bitness as the caller, only out-of-process invocation is a possibility, but the component needs to be registered accordingly for that. Somewhere with Office 2013 or thereabout there were multiple ways to install Office. One was a normal installer that got the registration for that usually right, the other was the so called click-to-run installer that pretty much always messed up the registration. Usually if you did a repair install of Office after that it magically fixed itself. Office 2016 had still that problem and with Office 365 I lost the overview as there seem to be zillion different ways and variants that can be installed, depending how your organization "purchases" Office licenses.
I never did much with Office from LabVIEW, and for normal work have long ago moved to Libre Office/Open Office.
@DavidBoyd wrote:
Of course you're right - I meant the Type Specialization Structure, not Conditional Compilation! Aaagh, sorry to all for mis-stating. And yes, the caveat is that the selection of unbroken diagram is a compile-time choice; if you want to build into an EXE or DLL etc, you must do the build on a machine that represents the target's version of Excel.
I did it in the past with dynamic call. Rebuild for each Excel (or Word) version the according VI and included them as external dependency. Then loaded and invoked them dynamically until one did load unbroken.
Works but is a total pitta to build. And very easy to fall over! And needs to be redone for each LabVIEW version again. I did it once for a customer project in my ignorance. Never ever again!!!! Or they would have to pay me double for every minute I invest in it! That usually stops such requests right in the tracks! 😁
"Ohhh we absolutely can do that. No problem! Costs 5000 bucks extra!"
"Let me think about this! I think we can mandate that the same Office version will be installed on all the computers!"
