Rif.: LabVIEW Report Generation Toolkit for Microsoft Office runtime consistency check

[rolfk]

I’m not at a computer for some time so can’t check your files. But rolling your own if you are going to use ActiveX or .Net is not going to solve the fundamental problems. Maybe you can increase performance in some areas but the fundamental problem remains. If you are going to use a third party library like XLSX IO or similar you have other challenges including having to compile it for every platform you want to support, such as Windows 32-bit and 64-bit, Linux, cRIO x64 and ARM, MacOS, and creating a very extensive LabVIEW library to access it. All doable but a lot of work!

[michele.santucci]

---

@rolfk  ha scritto:

The .Net interface to Microsoft Office is mostly just a hack. Under the hood it is nothing more than a COM Interop wrapper around the ActiveX interface. It may or may not circumvent this particular problem but overall you end up with this:

I don't know what .NET interface (maybe .NET MS Office Interop) you're referring to but I was talking of .NET OpenXML SDK that's completely different it does handle OpenXML formats from scratch without need of underlying COM and Microsoft Office. I used it in several kind of application (web and desktop) and I'm pretty sure it will work fine also in this case.. XLR8 works just this way and it could be a good solution also but I don't think it can be considered a one-on-one replacement.

[michele.santucci]

---

@joshua.l.guthrie2.civ  ha scritto:

Can you roll your own? 

I'm working on it on spare time (and I'm very short of time) so if you're looking on a short term replacement you can't count on me... but besides that I can share you the .net/c# code I'm working on so you can look at it if you wish.. just give me the time to build up a repo on github.

Anyway my idea is to write a .net assembly backed by OpenXML and build on them a LV library.

For some reason I cannot load your library but thnx for sharing (bear in mind that I'm working with LV 2013).

[rolfk]

Yes I meant the Microsoft Interop Office wrapper. I once briefly looked at it and decided that while the ActiveX interface was cumbersome, the .Net interop wrapper just added more crap on top of that.

A different 3rd party solution is another story. The XLR8 toolkit you mention does that too. It never was meant as drop in replacement for the RGT and I don’t see much use in trying to do that. Lots of extra work for very little gain. It may seem different to you but I have tried several such attempts for other things in my over 30 years of LabVIEWing and each and every of them never was even close to a finished library by the time I abandoned it out of frustration or boredom.

Instead focus on making a library that is useful for what you need to do and forget about trying to shoehorn it into a given interface like the RGT. It saves a lot of time and gives you the satisfaction to have done something useful and have an actually working thing too. Your RGT clone will always fall short in certain points no matter how much better it is, and suck your energy out of you.

[michele.santucci]

---

Instead focus on making a library that is useful for what you need to do and forget about trying to shoehorn it into a given interface like the RGT. It saves a lot of time and gives you the satisfaction to have done something useful and have an actually working thing too. Your RGT clone will always fall short in certain points no matter how much better it is, and suck your energy out of you.

---

That's exactly what I want to do.. are you sure XLR8 works trough MS Office Interop?

My RGT clone will not be a clone at all.. I just need to have a one-on-one replacement because I need to retrofit a BIG bunch of software where I need to change too many things and having a bunch of very different Vis to work with it will be a problem to manage.

[rolfk]

No as far as I know is the XLR8 toolkit using an independent .Net component called NPOI 2.1. It is after all advertised as not needing any Office installation to read and write XLS and XLSX files. The only drawback is that it is Windows only because of the use of a .Net component. And it is of course not free but we have burned more money discussing things in this thread alone than what they charge for one license!  Just food for thought. 😀

[michele.santucci]

---

@rolfk  ha scritto:

No as far as I know is the XLR8 toolkit using an independent .Net component called NPOI 2.1. It is after all advertised as not needing any Office installation to read and write XLS and XLSX files. The only drawback is that it is Windows only because of the use of a .Net component. And it is of course not free but we have burned more money discussing things in this thread alone than what they charge for one license!  Just food for thought. 😀

---

AFAIK OpenXML can be used in Linux also (trough Mono of course).

I definely need to give XLR8 a try but I'm pretty sure it's not a one-to-one RGT replacement so it will be painful to adopt it in my case.

[rolfk]

NPOI can be made to work in .Net Core aka .Net 8 too but while LabVIEW started to support .Net 8 assemblies in 2025Q1 this is still Windows only. 2025Q3 supposedly improved on that a bit but no fundamental changes were announced. If and when .Net Core support comes to LabVIEW for non-Windows platforms is still open for guesses.

And no XLR8 is not a drop in replacement for the RGT but if that is important to you, writing a wrapper around the XLR8 library that works like a drop in replacement is most likely magnitudes easier than writing your own from scratch. You still won’t have a library that automagically loads instead of the RGT but that remains the same with your own library from scratch.