dll creation with ActiveX property nodes

[madison7]

I am trying to build a simple dll of the attached code but am not having any luck with the header file syntax.

I am using ActiveX property nodes and automation refnums.

Appreciate any advice. Thanks!

[TCPlomp]

Well I don't think LabVIEW likes the fact that your FP terminals share the same name.

Ton

[madison7]

the names were different and i had the same failure to build. seems the problem is in the header file - just thought others may have had similar issues with header files. i can build a simple dll easy enough and this one is simple as well but for the ActiveX component.... thanks for taking a look.

[rolfk]

---

madison7 wrote:

I am trying to build a simple dll of the attached code but am not having any luck with the header file syntax.

I am using ActiveX property nodes and automation refnums.

Appreciate any advice. Thanks!

---

My guess is that LabVIEW has trouble to decide what data type to use for the ActiveX refnum. This is not a standard C type. In fact any refnums in LabVIEW are private and only meaningful in the process that created them. The only way you could make that work at all is by convertin/typecasting those refnums into an uInt32 and treat it as such. But that will require you to provide a complete DLL API to any method and property of your ActiveX object hierarchy your user might ever want to use, including the CreateObject method. A non LabVIEW process could never do anything meaningful with those refnums other than passing them back to the same DLL. And even when you would use this DLL in a LabVIEW application, would it only work when the LabVIEW version used to create the DLL is the same as the one calling into that DLL. Otherwise the DLL will run in its own LabVIEW runtime engine process and the refnums from the LabVIEW host process would be meaningless for the DLL and vice versa.

For what is this?? If it is for use in any Visual (Basic, C, etc) language it would be much easier for your users to simply use the ActiveX object directly.

If it is for LabVIEW just let the user use your VIs instead.

Rolf Kalbermatter

Message Edited by rolfk on 03-15-2009 10:10 AM

[madison7]

yes thanks rolf... i was making a feeble attempt to keep the calls proprietary. perhaps i should build a dll in another language and use that within the LV enviro.... your feedback is greatly appreciated!