Opening an Excel Workbook using .NET

[Soup]

I'm attempting to update several VIs that communicated with Excel (v. 2019) from using ActiveX to .NET ("Microsoft.Office.Interop.Excel(15.0.0.0)") in LabVIEW 2016 (Windows 10, & .NET 4.0). My development computer has the Excel version from Microsoft Office 365 ProPlus. I have been able to perform all the necessary methods, except Workbooks.Open or Workbooks._Open. I have confirmed the rest of the VI works by utilizing the Workbooks.Add method. Also, I have attempted wiring many combinations of some (and all) of the "optional" parameters for both the .Open and ._Open methods, but I always get the generic .NET Error 1172. What am I missing?

[MaSta]

Just wondering, because I also work with Excel files and neither use ActiveX nor .NET: why use any of these? They make your software dependent, because you need at least an installed Office on every PC you run the software on.

[Soup]

MaSta,

Thank you for your inquiry. Before this issue with opening an existing Excel workbook through .NET, it appeared to be a more direct and quicker transition to go to .NET from the original ActiveX. It was supposed to be a simple one for one replacement. As for .NET requiring Excel on each computer it is distributed, there is only a single costumer for this project and they use Excel, so it hasn't been a problem. I'm assuming you would suggest using the Report Generation toolkit, which I believe is my next best option if this issue is not quickly resolved.

[LucG]

@Soup

Did you find a solution to "open" a workbook with .NET in the end ?

I'm interested in the solution, if you have one. Thanks.

@MaSta

What are you using then to work with Excel files ?

I believe the Report Generation Toolkit uses ActiveX in the background, for example.

[Bob_Schor]

If you have the LabVIEW Report Generation Toolkit installed, working with Excel WorkBooks (even with multiple WorkSheets) is very straight-forward.  It does require that Excel be installed on the PC, as it uses Excel to "do the Excel stuff".  Note that the RGT is for true Excel files, .xlsx, not for Comma-Separated-Variable (.csv) files such as those created by LabVIEW's Read/Write Delimited Spreadsheet functions.

There's a Demo I posted here in 2014 showing the creation of a (single-sheet) Excel "Report" that includes several "Named" boxes (such as "Date", "Time", and "Operator", a columnar table of "Time, Temp1, Temp2, Temp3", 40 rows of 4 columns of data in the table, and a graph plotting these data.

You can find the Demo by searching this Forum and typing "Revised Excel" in the Search Bar and choosing the obvious choice.

As the Demo shows, the RGT can generate nice "Reports" as Excel WorkBooks.  Maybe less well-known, and a little more work, is that the RGT can also read Excel WorkBooks and, if you know the structure of the data or can "deduce" the structure (by, for example, reading the first row and from Column Headers deduce what data goes in what column), you can "fill in the Blanks" of a Template file.

Bob Schor

[Soup]

I did not find an easy solution for this problem, so I switched to developing the solution with LabVIEW's Report Generation Toolkit. It got more involved, but it works.

[Bob_Schor]

---

@Soup wrote:

I did not find an easy solution for this problem, so I switched to developing the solution with LabVIEW's Report Generation Toolkit. It got more involved, but it works.

---

I disagree.  You did "find an easy solution" -- it was two Posts ago, where I said "Use the RGT, it is quite easy to use and might be "the solution to your problem".  So go mark it as the Solution to help the others who might have a similar question.

Bob Schor

[LucG]

---

@Bob_Schor wrote:
I disagree.  You did "find an easy solution" [...]

---

Well technically Soup did not find a solution, since the topic is about using .NET for Excel files. Using RGT is a workaround, abandoning .NET for a totally different approach. This does not "solve" the .NET problem. The issue still exists.

That said, I will have a closer look into RGT, and into what you mention in your post, Bob. Thanks for the suggestion. I have already been using ActiveX for a long time, with success, to open existing Excel files, update values via LabVIEW, refresh data via DB (leaving Excel pulling data from a DB and refreshing its fields automatically), etc... This worked great for several years until recently, where a colleague started having error messages like "Element not found" when working with Excel files. "Reparing" the MS Office installation on the computer fixed the problem... for two days, and it came back. Same error, same solution. Now it works again. But for how long... We can't "repair" MS Office every two days. That said, there is probably something wrong with this computer in particular, as only one colleague has this issue, not the others, that use same LV runtime version, same Windows build version, same MS Office version. So I was looking for a different approach using .NET, hopping it would get me away from ActiveX. And if we have to install the .NET framework in addition, this is really no big deal.

So we'll see if RGT solves the problem, or if the guy needs to have his computer cleaned up (or wiped out and re-installed) by IT...

Luc