Leaderboard

Pretty simple except if you need to resize the array in the C code. You can let LabVIEW create the necessary code for the function prototype and any datatypes. Create a VI with a Call Library Node, create all the parameters you want and configure their types. For parameters where you want to have LabVIEW datatypes passed to the C code, choose Adapt to Type. Then right click on the Call Library Node and select "Create C code". Select where to save the resulting file and voila. This would then look something like this: /* Call Library source file */ #include "extcode.h" #include "lv_prolog.h" /* Typedefs */ typedef struct { LStrHandle key; int32_t dataType; LStrHandle value; } TD2; typedef struct { int32_t dimSize; TD2 Cluster elt[1]; } TD1; typedef TD1 **TD1Hdl; #include "lv_epilog.h" void ReadData(uintptr_t connection, TD1Hdl data); void ReadData(uintptr_t connection, TD1Hdl data) { /* Insert code here */ } Personally I do not like the generic datatype names and I always rename them in a way like this: /* Call Library source file */ #include "extcode.h" #include "lv_prolog.h" /* Typedefs */ typedef struct { LStrHandle key; int32_t dataType; LStrHandle value; } KeyValuePairRec; typedef struct { int32_t dimSize; KeyValuePairRec elt[1]; } KeyValuePairArr; typedef KeyValuePairArr **KeyValuePairArrHdl; #include "lv_epilog.h" void ReadData(uintptr_t connection, KeyValuePairArrHdl data); void ReadData(uintptr_t connection, KeyValuePairArrHdl data) { int32_t i = 0; KeyValuePairRec *p = (*data)->elt; for (; i < (*data)->dimSize; i++, p++) { p->key; p->dataType; p->value; } }

It should. The Report Generation Toolkit VIs are either built in (HTML Report) or access the according Word or Excel Active X component. However the Office ActiveX component is version sensitive. LabVIEW uses dynamic dispatch to access these interfaces, but uses early binding for that. It means it determines the actual method IDs to call at compile time rather than at runtime based on the method name. This has as consequences that the calling is slightly faster but any version difference in the ActiveX interface leads the LabVIEW method call into the abyss. So your Office installation on the target machine has to use the same version as what was used on the machine on which you build the application. The change to use late binding would have been fairly trivial for anyone having access to the LabVIEW source code, but alas was never considered a strong enough issue to let a developer spend a few hours on it. If I would have had to do it I would probably have left the early binding option in there and added an extra retry to try late binding at runtime if the initial methodID call would fail. Or even fancier, let the ActiveX method call have a menu option to select if it should do early binding, late binding or a combination of both with retry if the early bind call initially fails.