64-Bit Microsoft Excel with 32-Bit LabVIEW Environment

[Andrew_F]

I have recently installed Both LabVIEW 2024 32-Bit and 64-Bit development environments.  I am running into issues related to Microsoft Excel (Excel 2016 64-Bit) when operating from the 32-Bit LabVIEW environment.  This issue has come up before and I have read through many threads going back to LV2017 surrounding the Report Generation Toolkit and issues with various iterations of Microsoft office (360, 32-bit/64-bit and various office year versions).  The specific issue is that when trying to use the "Save Report To File.vi" from the toolkit, the call fails with an error:  Some other threads that I have read through reference this type of behavior, but nothing comes up more recently.  I have tried 'repairing Microsoft Office app' through windows settings with no luck.  

I'll probably phrase this wrong but...How do I point LabVIEW 32-BIT to the proper library to get the property node members and functions which seems to be the issue?  Using the LabVIEW 64-Bit environment is an obvious solution, but it presents other issues that do not pertain to this topic.  Using a 32-Bit version of Office is not an option either in my situation.  And, as I've asked before in a previous thread, how is it that some of these property node calls are able to operate and others aren't?  I'm able to open Excel, Insert Text, but saving is an error.

Threads that I have gone through and followed to other threads on the topic:

Problem with ActiveX Excel automoation, LV2019SP1 32-bit, corporate Office 365/Excel 2016 

My own thread from years ago discussing similar ActiveX behavior 

The error:

-2147352573

Member not found.  in NI_ReportGenerationToolkit.lvlib:Excel_Save_Workbook.vi->NI_Excel.lvclass:Save Report to File.vi

Two main topics come up discussing this type of issue going back years.  Two main issues are discussed.  First is "broken vi's".  In my case there are no broken VI's.  The second issue involving the ActiveX calls (property and invoke nodes) not able to find the proper dll's (or whatever it is that they are finding the member properties and functions from).  The second case seems to be the issue.  When I dig into the RGT vi's I get down to property nodes that can not find members.  They show as if they exist, but if I were to drop a fresh property/invoke node and wire it to the reference I get no visibility into the functions/members.

What is strange about this is that the toolkit seems to be able to use the RGT and ActiveX calls for most of the functions.  This one in particular fails with an error and I create and save a new document.  I have generated an identical VI using the LabVIEW2024 64-Bit environment and it operates flawlessly.  Here's a screenshot of the simple Open and Save VI that I am using as a test:

[Bob_Schor]

For at least a decade, I've been using 64-bit Windows (7 and 10), 32-bit LabVIEW (from 7 through 2019 and 2021), and 64-bit Office.  A decade ago I posted a "Revised Generate Excel Report Example" on the Forum (you can find it by typing the beginning of the title in the Forum's Search Bar, and it will pop up) which continues to generate an Excel Report with tables, simple entries, and even a graph of one of the data tables, even though at least one of the functions (I don't remember if "New Report" is now "Create Report", or visa versa), and the code still works fine.

I'm 95% confident that the RGT is still functional, even with LabVIEW 2024 (though I admit to not having tested it -- I should build a VM and see if I can get it to work).  Installing LabVIEW has gotten a little more complicated and troublesome, possibly because of the temptation to "install everything" rather than my philosophy of "install the minimum that you need, you can always add later".

Just in case it "rings a bell", can you tell us some more specifics?

• What version of (64-bit) Windows are you running?  [I've yet to venture into Windows 11 ...].  List all that apply, please.
• What (I don't know the terminology) of LabVIEW, Base, Full, Professional, Academic, Community have you installed?
• Have you ever uninstalled LabVIEW?  [This is particularly important, as it can "poison" a Windows platform for future LabVIEW use].

Bob Schor

[Andrew_F]

I'm using Windows 11 Pro

The LabVIew environment is Professional.

I do not believe that I have uninstalled LabVIEW on this PC.  I do have LabVIEW 2023 32-Bit installed as well.  Typically I would have even more environments installed to maintain old software (I might have more installed but didn't look hard enough to find any others).

I have not dramatically explored the entire toolkit for full functionality.  The 64 Bit LabVIEW environment does not seem to have any issues.  And as stated there are other reasons that it would be difficult to use the 64-bit LabVIEW environment for the project I'm working on.  Frankly I find the toolkit to be mostly useless.  Mostly I will use the report toolkit to open/create/save office documents, but I will typically generate my own VI's to interact with Word and Excel.

Do you have any insight on how to 'relink' the property node calls?  I know that there are workarounds such as having the user explictly save the document.  This would work, but experience shows that the user is 99% likely to fail properly storing files in their correct location.

[ooth · Accepted solution]

I'm not sure if you tried this but I found that is helps to relink the nodes.

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

[Bob_Schor]

I just ran my 10-year-old "Revised Generate Excel Report Example" (mentioned in an earlier post) on my Windows 10 (64-bit) Laptop, with Microsoft 365 (Office) 2021, 64-bit (not 2016!), LabVIEW 2019 (32-bit), and it ran just fine, producing the expected Report.  The previous reply noted a possible "Bitness" problem with Office 2016 64-bit, but I'm pretty sure I've also been successful with this version (the only thing being 32-bit is LabVIEW), but I'm not sure if any of my other systems have this configuration now ...

Bob Schor

[ooth]

This is very strange and probably not related to the OP's problem but I'll comment it here just in case someone else runs into the problem.

When I tried running your demo or even using RGT Create Report.vi my LV2021 32-bit crashed. I'm running Windows 10 and Excel 2016 64-bit. I tracked it down to the subVI NI_ReportGenerationToolkit.lvlib:Excel_open.vi. (Shown below)

For some reason the crash happened when the property node was reading the Version so I removed it and Excel now opened without crashing LabVIEW.

[Bob_Schor]

---

@ooth wrote:

When I tried running your demo or even using RGT Create Report.vi my LV2021 32-bit crashed. I'm running Windows 10 and Excel 2016 64-bit. I tracked it down to the subVI NI_ReportGenerationToolkit.lvlib:Excel_open.vi. (Shown below)

For some reason the crash happened when the property node was reading the Version so I removed it and Excel now opened without crashing LabVIEW.

---

Thank you for that follow-up.  Microsoft has done a very good job of hiding such things as Version number and 32/64-bit settings, but I was able to verify that I'm currently running on my main Work PC Excel for Microsoft 365, Version 2402, and it is 32-bit.  I'm pretty sure somewhere I have an Office 2016 64-bit installation, but for all I know (who checks?), Excel may also be 32-bit ...  Anyway, this may well explain "why it works for me" (because I didn't know what I was running).  It doesn't need to be so complicated ...

Bob Schor

[Andrew_F]

Thanks ooth!  Well, that seems to answer that question.  LV32bit just won't work with Office 64Bit.  

So, how does it 'sort of work?'  In my case, it opens excel just fine, I can add text using other RGT vi's, but it fails with error when attempting to save the file.  Is it loading the 64 bit dll's or something and they are quasi compatible?  I might just have to bite the bullet and address the other reasons that I reverted to using LV2024 32-Bit instead of LV2024 64-Bit.  

So, I followed the procedure for pointing the Excel._Application reference to the EXCEL.EXE and voila!  Seems to be fully operational now.  The save function now works without modifying anything else.  

[ooth]

I'm glad to hear it worked. The only problem (for me) is when I apply the solution LabVIEW doesn't remember the fix. What I mean is next time I open LV the property nodes show "No Methods" if I click on them. But the VIs run and work correctly so I'm not too concerned. Only if I have to change something do I have to re-apply the solution so all the options show up again. Probably has something to do with how Office was installed on my PC.

[Andrew_F]

Well, it's only a partial solution.  While playing around some more, I've experienced a crash from LabVIEW and just as you commented, when LabVIEW reloaded the member functions in the property node were once again missing.  So, it does seem to be a partial fix.  I was trying to implement other features using the property nodes and I would say that this bitness mismatch is just not a safe option.  I'll leave the solution in place as it does seem to temporarily fix the problem, but truly it's not a good solution at the moment.  Until I find a better solution I'm abandoning this effort to get the match and will work in the LabVIEW 64-Bit environment.