LabVIEW
ActiveX changes in Excel versions?
Yes, there are differences in the ActiveX API between every version of Microsoft Office. However, don't despair! It might be easier to fix your error than you think.
First of all, the reason that you get a broken arrow when opening the VI on the Excel 2000 machine is that LabVIEW reads the type library file (*.tlb) that belongs to the version of Excel that is installed on the machine. This file determines the available methods and properties of the Excel ActiveX server - in other words the ActiveX API needed to access Excel. If some of the methods or properties that were saved with the VI when it was created on the Excel 2002 machine are not present in the API for the Excel 2000 machine, LabVIEW will notify you with a broken arrow. Clicking the broken arrow will take you to the Invoke Node (for methods) or the Property Node (for properties... duh!) that has a mismatch between the method/property in the VI versus the one in the API. The wire will not be broken, so it might be confusing to see what is wrong the first time. However, all you have to do is use the finger tool to click on the Node to bring up a list of available methods/properties. Notice that the method/property that originally was showing in the Node is NOT part of the list, since this list is defined by the *.tlb file. What you should do is choose another method/property that will do what you need instead of the original one.
One of the most common issues between Excel versions were the change from using the "Value" property to using the "Value2" property between version Excel 97 and 2000 (as far as I remember). The fix was simply to choose "Value2" instead and the VI would then run fine.
Here's a KnowledgeBase that talks about some of these version specific issues with ActiveX and Excel:
LabVIEW's ActiveX Examples for Microsoft Excel 97 with Newer Versions of Microsoft Excel
BC, please let me know if this explanation helps you solve the issue, thanks.
Have Fun!
Message Edited by Philip C. on 09-19-2005 10:51 PM
You could try using the .NET controls for Excel automation?
I think they're just wrappers for the ActiveX controls so all of the parameters and function names are the same for the most part.
@ico82 wrote:
I have never used .NET so it add difficult and I suspect that just move the problem in another discussion.
Ok, to relink the method is normal (also if method is identical defined), is there a way to programmatically relink the method in an executable? I don't think. Is there a way to save my ActiveX version also in a machine where a different version is installed? I think it give licences problem.
Is there a solution?
No. LabVIEW programs are fully compiled and changing the code in an executable is not an option!
The only way to work around this if you need to support multiple Excel versions is to use dynamic loading.
You create a caller that uses VI Server to locate the correct VI for the currently installed Excel (and other Office application) version and then call it. You need to maintain also different VIs with the same calling interface for each version you want to support. And yes you only can create/modify each relevant VI on a system with the according Excel (Office) version. In order for the VIs to be executable in an executable they need to be compiled in the according LabVIEW version and the binary code needs not to be seperated from the VI. And that needs to be done for each Excel (Office) version you want to support too.
In terms of ease of maintenance this is a pretty terrible solution.
Not really easier but a lot more maintainable is likely to simply create an external DLL in C++ that does not change the API and call that Excel API from there. If you use proper COM/ActiveX mechanisme like IDispatch you can discover what the current method requires as parameters and pass to all the unused optional parameters a variant initialized as follows:
VARIANT var;
var.vt = VT_ERROR
var.scode = DISP_E_PARAMNOTFOUND.
Visual Basic (and VBA) does this automatically and that is why it seems to work, but in C++ you have to do that explicitedly and the LabVIEW interface for ActiveX is written in C++. The code generator determines the number of parameters at compile time and that is why it fails when the ActiveX method suddenly has a different number of paramters. Theoretically LabVIEW could do the determination of the ActiveX interface also at runtime through the IDispatch interface but that would be a serious performance hit as it would be something to do either for all ActiveX methods or none. Of course it could also allow to add a user selectable option if the method interface should be resolved with IDispatch at runtime or compile time and that would resolve this once and for all, but ActiveX is already a legacy technology and the likelyhood that NI is spending such significant development effort for a legacy technology is about 0.1%.
