LabVIEW
LabVIEW, ActiveX, one EXE to work with two OLBs(?)
Greetings!
I inherited a "large" application that was running under the LabVIEW IDE and Windows 2K. The application uses (ActiveX) calls to an Excel 9.0 Type Library.
When I compile (LV7.1) the app on my WinXP workstation, and run it on the Win2K station, one of the ActiveX calls don't work anymore - reporting some ActiveX "Server" error (possibly related to use of an XLT "template".).
I thought if I could compile with exactly the same (older) libraries as exist by default under Windows 2K, then the EXE would work there - and possibly also under XP, however
On the the development station, LVs ActiveX browser-dialog lists Excel 11 Type Library, but not 9.0.
I've tried explicitly browsing to Excel9.olb (which I copied from the 2K station to the XP development station), but the "Type Library" box continues to report "Microsoft Excel 11.0 Object Library..."
Q. How can I force LabVIEW (or XP) on development station to use older Microsoft Excel 9.0 lb Object Library
I think this has been asked/answered before - but I'm having trouble searching&finding applicable posts!
Thanks.
Thanks for replying Mike.
It seems that LabVIEW uses late-binding when using ActiveX refnums. The ActiveX Event Callback for Excel.vi which can be found in the NI Example Finder should work with any version of Excel granted that the version supports the Excel._Application Automation Object. You could verify this by running the example on your computer with Excel 11.0 installed, saving the VI and sending it to the customer with Excel 9.0 installed to make sure it still works. I was also able to run example VIs found on our website intended to be used with Excel2000 without any problems (I have Excel2007 installed).
I looked at the ActiveX Event Callback example but am not sure how it can help with the problem of correctly linking to platform-specific Object Library at run-time. It illustrates how to invoke a single VI that accesses Excel methods & functions. But this VI is still compiled while bound to the 11.0 Library like my code - which won't work with Excel2000 (Microsoft Excel 9.0 Object Library.)
I would be surprised if an ActiveX control could be created with late binding though so any ActiveX controls on the front panel will most likely use early binding and you may run into problems with different Object Libraries.
Fortunately, no FP controls to worry about!
When running under the IDE, the ActiveX differences (between dev. stn and target) got resolved on the target by editing and saving there. The "Editing" consisted of finding the broken diagram and reselecting the Open method for a workbook or worksheet (I don't remember which.)
One thing that also comes to mind is if issues will only be seen in a built application. Do you know if this error is only seen in a built application or not? Did your workaround correct the issue? If so, could you post a screenshot of how you implemented the workaround for the community's benefit?
One solution is to wrap the OLB-specific code in an Excel "Driver" VI, and make two copies of that VI - one saved while bound to the 11.0 OLB, one saved while bound to the 9.0 OLB. At run time, interrogate the platform to decide which OLB is present and use call-by-name to load/run the suitable VI.
I'd like to cooperate with a screenshot, but my lazy solution chose the VI based on OS (not OLB), consequently, it only works if all XP stns use the 11.0 OLB and all the 2K stns use 9.0. We released the code and immediately encountered an XP stn with Excel 2000 (9.0 OLB) - of course! (instead of revving SW to fix this bug, we're going to upgrade one test-stn to Office 2003.)
Another shortcoming of my solution is that, I think, the functionality of these Excel driver-VIs should be implemented in DLLs - to help make them portable and insulate them from accidental editing. I found the IDE - but not the Application Builder - installed on stn where the Excel 9.0 Object Libraries were, so could save a VI there, but not compile it. That led to use of call-by-name method instead of DLLs.
[1]Do any of the ActiveX calls work or is it one specifically that's reporting this error? [2]Does the Win2k machine have LV development? If so, you can create a debuggable executable to test that as well as testing the VI without being built into an app. Otherwise, I'd suggest using error indicators at specific key points to see when you're getting errors. If it's an issue of the early binding, I'd expect an error from the Open Automation VI. [3]Also, did the version of LabVIEW change at any point? Thanks tbd and I look forward to hearing back from you!
(1) Some calls work, some don't. I don't have the exact error-detail for the one(s) that didn't, but remember the error-text suggested Excel's ActiveX Server was unhappy about one of the calls - Workbook "save as" I think.
(2) Yes, but source code always worked on target (once property/methods were re-linked.) Made several EXEs that opened the FP of the Excel VIs, and saw the "ActiveX Server" error that way.
(3) 
, target was running 7.1, dev stn is 7.1.1
, target was running 7.1, dev stn is 7.1.1 Thanks and Cheers!
Hi Jennifer,
Since you've already given me credit for it 
- here's my "hack" for "late-binding".
Though this kind of solution has appeared before on this forum, maybe this additional post will be helpful to someone who's stuck in a similar situation. It took me too long to figure-out that Excel would tell me what OLB to expect - see VI attached!
Cheers.
Message Edited by tbd on 06-10-2008 10:00 PM
Office 9.0 typelibrary supposedly is Office 2000. Version 11 is Office 2003.
@tbd wrote:
Hi Jennifer,
Since you've already given me credit for it
Though this kind of solution has appeared before on this forum, maybe this additional post will be helpful to someone who's stuck in a similar situation. It took me too long to figure-out that Excel would tell me what OLB to expect - see VI attached!
Cheers.
Message Edited by tbd on 06-10-2008 10:00 PM
What you did is almost what NI does in the Report Generation Toolkit except the dynamic recogniztion of the installed Office typelibrary version.
They have a VI library that implements the actual Excel (and Word) ActiveX nodes for each supported Office Version and needs to be added to the build as dynamic VIs. The VIs you put in your application are just CallByReference wrappers to these actual VIs. So in this way you can only support one Office version in a specific build application.
The problem is not late binding which LabVIEW uses but instead the fact that MS changes the actual signatures (number and type of parameters) of methods between Office versions. LabVIEW's binding is not meant to adapt to signature changes on the fly and I doubt that it could actually do that easily since it involves a recompile. Maybe that a dynamic scripting interface like Python could do it but compiled environments like C would be in trouble too with that.
Rolf Kalbermatter
Message Edited by rolfk on 06-11-2008 07:54 AM
I was refering to the Report Generation Toolkit. The different Office version libraries contain the same VIs compiled for the specific Office version. You include the one you want to support on the target into the build but can not include multiple of them into the same application.
@tbd wrote:
@rolfk wrote:
They have a VI library that implements the actual Excel (and Word) ActiveX nodes for each supported Office Version and needs to be added to the build as dynamic VIs. The VIs you put in your application are just CallByReference wrappers to these actual VIs. So in this way you can only support one Office version in a specific build application.
Message Edited by rolfk on 06-11-2008 07:54 AM
Hi Rolf,Not sure what you meant by "in this way you can only support one Office version in a specific build application" - example supports two OLBs (call to 11.0 is in a different case) but method could support an unlimited number of different Office versions.My [likely] mistake re: "late binding" somes from this post which is discussing LabVIEW polymorphism (see post by Greg McKaskle.) A search on this subject shows other (VB) programmers encounter this same problem - which they solve through explicit late-binding syntax.Cheers!
Late binding means a lot of things to a lot of different people. Basically it really means that the linking (binding) is not done on load time but at the first time the function is called. And from that LabVIEW does do this in Active X if I'm not mistaken. That doesn't solve the problem of an Active X method changing it's calling interface since LabVIEW defines the calling interface at compile time (except probably for Variant defined parameters which LabVIEW can adapt to at runtime). But for non Variant parameters or when suddenly there is an extra parameter or one less, LabVIEW has to throw the towel and refuse running that method since the Call Interface was compiled and prepared at build time and can not change at runtime. The same is true for C(++) where the compiler defines the method interface and as it seems even Visual Basic does the same. Of course you can prepare your code to run for different versions by implementing all the method call versions and detect which is necessary at runtime. Which you do now but while this is late binding too it's not the only way of late binding. Even Windows DLLs have delay load imports (which is also a form of late binding) which means Windows will only intilialize the
function import stub at the first time the function is used. This is still strictly linked but has been introduced to allow for circular references of DLL imports. Without delay loading Windows would get into a problem loading a DLL that references another DLL that references back to our first one and the loading would fail since all direct imports need to be fully satisfied before the load of a DLL can succeed.
Rolf Kalbermatter
Message Edited by rolfk on 06-11-2008 08:36 PM
