I need help with NI_Excel.lvclass

[felipejorge]

Hi, I have to do modification on a vi that uses multiples functions from NI_Excel.lvclass, which is blocked. When I try to open a .vi that uses something from that class, labview imediatly closes or crash.

I have the Labview 2018 Pro, with the report generation tookit for MOffice 2018, both licensed in the license manager.

Have someone had this problem before? What can I do do unblock it?

Thank you.

[Bob_Schor]

The NI_Excel.lvclass, I believe, is designed to (only?) work with the NI Report Generation Toolkit, which (in turn) interfaces with Microsoft Excel.  I've used the RGT to read/write Excel Workbooks for multiple versions of LabVIEW, including (I think) LabVIEW 2018.  As far as I know, the base functions housed in vi.lib (such as NI_Excel.lvclass) are sub-VIs that NI has written to carry out the functionality of the RGT -- they are designed to work with each other, and are not designed to necessarily be "user-modifiable" (if there is such a word).

What, specifically, are you trying to do?  You should, ideally, attach not only a description of "What", but also your own LabVIEW example of "How" (you tried to do it), that exhibits the "blocking" behavior you mention (I'm uncertain what "block" actually means, but if you provide code and possibly an example Excel Workbook, we can "try it ourselves" and be better able to make helpful suggestions).

Bob Schor 

[felipejorge]

I cant open any vi from the NI_Excell.vclass. If I do Labview crashes.

If I try to open any .vi that calls a .vi from this class, Labview closes, no errors are given.

When I say that the .vi is blocked, it means that it has a paddlock symbol and there is a password input option. But I have the Report Generation Toolkit 2018 licensed.

I need to open the main .vi froma software but as it calls .vi from that class, labview keeps closing.

I tried reinstall, re-applying licenses, and repairing everything but it didn't make a change.

[BertMcMahan · Accepted solution]

Definitely sounds like it's corrupted somehow. FWIW, the NI_Excel class is locked on my end as well, but it's the library that's locked. You can still view the VI's and see their block diagrams. Generally speaking, the NI_Report VI's are very easily user-accessible and modifiable (if they're not corrupted, of course). They don't always have the functions I need so I have had to update and tweak on them some which is quite easy to do... if the VI's open 😉

Try clearing your compiled object cache. You might also need to reinstall Excel. Speaking of which- what version of Excel are you using, and what bitness LV are you using? The RGT doesn't work with 32-bit LabVIEW anymore since Microsoft removed 32-bit support from Office.

[felipejorge]

Reinstalling excel worked

Thank you!

[BertMcMahan]

Glad to help. BTW, the NI Report stuff just passes some data to Excel ActiveX (IIRC) code. Most of the work is being done within Excel, not LabVIEW. When you're having strange issues with the reporting tools, check the Excel installation and version/bitness compatibility first. Error handling between the Excel side and the LabVIEW side isn't great.

[Bob_Schor]

---

@BertMcMahan wrote:

Speaking of which- what version of Excel are you using, and what bitness LV are you using? The RGT doesn't work with 32-bit LabVIEW anymore since Microsoft removed 32-bit support from Office.

---

I believe that the RGT does work in 32-bit LabVIEW with the current (?) version of Office. I posted an Excel Demo on the Forums in 2014 that uses quite a few of the RGT basic tools for creating Excel reports, and it runs just fine.

I open LabVIEW using an Icon that has the NI Label "NI LabVIEW 2021 (32-bit)", and my version of Excel is also 2021.  I did not install 64-bit LabVIEW on this PC (I'm not sure I've ever installed 64-bit LabVIEW).

Bob Schor

[BertMcMahan]

You're right, I stand corrected! Thanks Bob.

https://www.ni.com/en-us/support/documentation/compatibility/17/report-generation-toolkit-and-micros...

It's strange because I actually migrated to LV 64-bit precisely because it wouldn't work with Office anymore after we did an update.

Apparently my problem was using 64-bit Office with 32-bit LabVIEW, and that combo isn't allowed. Any other combination of bitness is OK (i.e., matching or using 32 bit Office with 64 bit Windows).

So, OP- my earlier advice stands if and only if you're using 64-bit Office, which my company was using which made us switch to 64-bit LabVIEW.

[Bob_Schor]

---

@BertMcMahan wrote:

You're right, I stand corrected! Thanks Bob.

https://www.ni.com/en-us/support/documentation/compatibility/17/report-generation-toolkit-and-micros...

It's strange because I actually migrated to LV 64-bit precisely because it wouldn't work with Office anymore after we did an update.

Apparently my problem was using 64-bit Office with 32-bit LabVIEW, and that combo isn't allowed. Any other combination of bitness is OK (i.e., matching or using 32 bit Office with 64 bit Windows).

So, OP- my earlier advice stands if and only if you're using 64-bit Office, which my company was using which made us switch to 64-bit LabVIEW.

---

Sigh.  I had no idea if my version of Office was 32-bit or 64-bit (I purchased it when I got my new Laptop from Dell about a year ago).  I also wasn't sure how to find out, but found the following somewhere in "About Excel":

I do know that when I installed Office 16 on my older machine, I always used the 64-bit version (because, why not?).

Not sure why Bert was having problems -- maybe there was something special/unusual he was doing, but I've used many of the RGT functions, blithely unconcerned about mixing 32-bit LabVIEW with 64-bit Excel, and never had (much of) a problem.  [There is the "timing issue" when you write and "dispose Report" Excel -- you can't re-open it right away without Bad Things Happening.  I had a number of routines that did this, and without a short delay, maybe a few tenths of a second, it wasn't pretty ...].

Bob Schor

[BertMcMahan]

Poking around, it looks like it works for some people and not for others (for example). Seems like it may have something to do with the way you installed it, like the "click to run" version vs standalone vs Office365... There's some ActiveX stuff that gets squirrely on you and may or may not install correctly, but will if you do a "repair" after the fact. It also appears that sometimes it may not let you pick new properties or methods, but will actually run fine anyway (another example).

Bob, were you running Office 365? I was using standalone Excel and I *think* it was version 2016. This was several years ago so my memory's hazy. I do recall it was some old code that broke suddenly after some change to Office, which prompted my switch to 64 bit. IIRC it even broke my compiled executables.

Although since mine, yours, and OP's install all work fine, I suppose this is mostly academic at this point 🙂

To sum up: Try to match bitness, but it may work fine anyway 😄