Read Excel spreadsheet from Excel 2000 and/or 2003

[TroyK]

I need my application to be able to read excel spreadsheets on a PC that has either excel 2000 (version9) or excel 2003 (Version11) installed on it.

In the ActiveX methods I'm using, the only difference between the 2 versions is the 'Workbooks' -> 'Open' method.
I can check the excel version number then select which version of the method to use, but it won't compile!
I can get xl2000 to work if I compile my exe on a machine that has excel 2000 on it.
I can get xl2003 to work if I compile my exe on a machine that has excel 2003 on it, but not both!!!

I've tried installing both versions of excel on my PC, that doesn't work because microsoft seems to have used the same ActiveX IDs for both versions of excel. Only the Excel 11 ActiveX controls are available to use in LabVIEW.

I can copy a working excel 2000 vi onto the machine with excel 2003 then it only breaks when I try to compile it.

What I think I need is a way to get the LabVIEW 8.2 application builder to ignore the broken method/sub-vi. It should work when it's on a machine with the matching version of excel on it.

Is there a way to do this? It's driving me nuts!

[mikeporter]

Ok, one solution that I can think of is to make the excel interface routines dynamically linked. Put the routines themselves in a llb that is included in the build as a "support file" - that way the builder won't try to do anything with it other than load it where you tell it to. In your application's ini file you can put a new key that specifies which of the plugins in the library to call. I know that this is sort of a "broad brush" description. If there are specifics you have additional questions on (like: how to build the LLB; or how to do they dynamic linking in such a way that there is no performance hit; or how to find the plugins at runtime), ask away...

Mike...

[TroyK]

Opening an instance of excel takes a while anyway and I don't do it that often so I'm not too concerned about performance.

I have tried to dynamically load the vi's but the application builder still flags the dynamically linked vi's.
I haven't tried building a llb. I'll give that a go now... thanks for the tip.

I'll let you know how it goes... or ask more questions if I get stuck again.

[mikeporter]

The key point is including the library as a support file so the builder doesn't try to treat it like a LabVIEW file...

Mike...

[TroyK]

I can't get it to work exactly the way you've suggested.  I put the vi's in a llb.  To include the llb as a support file it has to be in the project.  As soon as I drag the llb into the project it adds it as a folder containing the vis (which it checks during the build and fails to build). However if I build the application without the llb as a support file or anything, then copy the llb into the application directory, it works!!!

It's a dodgy work around which I wont be able to distribute but at least it is a start. Am I missing something with the llb which will allow me to add it to the project without the project explorer trying to do anything clever with it?

[TroyK]

Alright... this is probably one of the dodgyest work arounds you've ever seen but I got it to work by renaming the .LLB to .LLLB (note three L's in .LLLB) When I drag that into the Project it does nothing because it doesn't recognise it. However, now if I dynamically call a vi inside my LLLB it works!!!. I can now compile the vi and (hopefully) include this work around in an Installer... we shall see.

Message Edited by Troy Kujawski on 05-21-2007 05:08 PM

[mikeporter]

Actually, that's one of the next things I was going to suggest. Due probibly to it's Mac heritage, LV doesn't pay a whole lot of attention to things like file extensions. When it comes to accessing VI's programatically it just goes and looks where you tell it to.

Mike...

[smercurio_fc]

I don't know if this is feasible for you, given that it would require code changes, but you should be able to access Excel files using the ODBC driver, and it doesn't care which version of Excel is on there. In essence, you treat an Excel worksheet as a database.

[mikeporter]

I thought of that as well, but have never actually tried it. Where might one find a good explaination of how that interface works? What would the "SQL" look like?

Mike...

[TreyB_NI]

Another work around would be to first determine which version(s) of Excel that is on your machine, and then call dynamic VIs or already compiled code specific to that version of Excel.  See the attached VI to see how to detect the version of Excel.