How to match the data type when I call a DLL

[Yanan]

I met some problems when I use LabVIEW call external DLL function. the source C code is as following.

What kinds of data types should I use for "name" and "value" when I configure the call library function?

I tried a few. however, some will cause the program crash, and some will not working without any error.

Thank you very much!

Yanan

============================

Syntax:

int xiaSetAcquisitionValues(int detChan, char *name, void *value)

Usage:

int status;

double new_threshold = 1000.0;

status = xiaSetAcquisitionValue(0, “trigger_threshold”, (void *)&new_threshold);

[Francois Normandin]

Syntax:

int xiaSetAcquisitionValues(int detChan, char *name, void *value)

I think char is INT8 and void is "Adapt to Type" in LabVIEW dlls.

I could be wrong, as I don't use DLLs a lot in LabVIEW... but try this:

char *name ==> type: Numeric; Data type: Signed 8-bit Integer; Pass: Pointer to Value

void *value ===> type: Adapt to Type; Data Format: Handles by Value

[ShaunR]

I met some problems when I use LabVIEW call external DLL function. the source C code is as following.

What kinds of data types should I use for "name" and "value" when I configure the call library function?

I tried a few. however, some will cause the program crash, and some will not working without any error.

Thank you very much!

Yanan

============================

Syntax:

int xiaSetAcquisitionValues(int detChan, char *name, void *value)

Usage:

int status;

double new_threshold = 1000.0;

status = xiaSetAcquisitionValue(0, “trigger_threshold”, (void *)&new_threshold);

Yup. Dlls are a nasty business. I avoid them when I can.. I presume it is a dll written in C or C++?

For *char (i.e name) you can use a "String" Type with the "C String Pointer" Format.

Int will depend on how the dll was compiled (32 bit or 64 bit). An int compiled for an x32 will be I32 Integer. For 64 bit it might be I32 or I64 (it's up to whoever compiled it).

Void is just an untyped pointer to something (could be a byte (U8), 2 bytes (int32), 4 byte (Int 64) a double (8 bytes) and so on). So you have to know the size of that something. If it is an integer, you need to know if it is 64 bit or a 32 bit. If it is a double (floating point) then you need to choose double (it will probably be be 8 bytes - I've never seen a 4 byte one in a C/C++ dll). Then choose "Pointer To Value"

If you look at the function prototype, it will show you what the C calling format is for your function. By selecting the appropriate drop downs; replace "Int" with Int32 or Int64 (depending on what it was compiled with).

So your Labview function prototype might look something like

int32_t xiaSetAcquisitionValue(int32_t detChan, CStr Name, int32_t *Value);

or if the value parameter is a floating point number then

int32_xiaSetAcquisitionValue(int32_t detChan, CStr Name, double *Value);

If Value parameter can be any type depending on the "Name" that you are setting, then you can use the "Adapt To Type" and define it in your labview code for each call by just wiring a U32, Dbl or whatever.

Edited December 7, 2010 by ShaunR

[Yanan]

ShaunR & Francois

Thank you very much! I will tried what you suggested.

Yanan

[Yanan]

Hi ShaunR,

It works now!!

Thank you very much!

Yanan

Yup. Dlls are a nasty business. I avoid them when I can.. I presume it is a dll written in C or C++?

For *char (i.e name) you can use a "String" Type with the "C String Pointer" Format.

Int will depend on how the dll was compiled (32 bit or 64 bit). An int compiled for an x32 will be I32 Integer. For 64 bit it might be I32 or I64 (it's up to whoever compiled it).

Void is just an untyped pointer to something (could be a byte (U8), 2 bytes (int32), 4 byte (Int 64) a double (8 bytes) and so on). So you have to know the size of that something. If it is an integer, you need to know if it is 64 bit or a 32 bit. If it is a double (floating point) then you need to choose double (it will probably be be 8 bytes - I've never seen a 4 byte one in a C/C++ dll). Then choose "Pointer To Value"

If you look at the function prototype, it will show you what the C calling format is for your function. By selecting the appropriate drop downs; replace "Int" with Int32 or Int64 (depending on what it was compiled with).

So your Labview function prototype might look something like

int32_t xiaSetAcquisitionValue(int32_t detChan, CStr Name, int32_t *Value);

or if the value parameter is a floating point number then

int32_xiaSetAcquisitionValue(int32_t detChan, CStr Name, double *Value);

If Value parameter can be any type depending on the "Name" that you are setting, then you can use the "Adapt To Type" and define it in your labview code for each call by just wiring a U32, Dbl or whatever.

[Rolf Kalbermatter]

Int will depend on how the dll was compiled (32 bit or 64 bit). An int compiled for an x32 will be I32 Integer. For 64 bit it might be I32 or I64 (it's up to whoever compiled it).

Actually it is a bit more complicated (or not) than that. On all 16 bit systems int used to be 16 bit and on 32 bit systems it is 32 bit. So far so good.

For 64 bits things get a bit messy. int here is still always 32 bit (well for the majority of systems, some more exotic systems use actually 64 bit int's) as detailed here (Specific C-language data models).

The most interesting part is however with longs where Linux 64 bit uses 64 bits, while Microsoft Windows chose to use 32 bit longs.Linux is more forgiving to code that casts pointers into longs while Windows is more forgiving to code that assumes sizeof(long) == sizeof(int). Both assumptions have of course no place in modern software, but many programmers can be sometimes a bit lazy.

[ShaunR]

Actually it is a bit more complicated (or not) than that. On all 16 bit systems int used to be 16 bit and on 32 bit systems it is 32 bit. So far so good.

For 64 bits things get a bit messy. int here is still always 32 bit (well for the majority of systems, some more exotic systems use actually 64 bit int's) as detailed here (Specific C-language data models).

The most interesting part is however with longs where Linux 64 bit uses 64 bits, while Microsoft Windows chose to use 32 bit longs.Linux is more forgiving to code that casts pointers into longs while Windows is more forgiving to code that assumes sizeof(long) == sizeof(int). Both assumptions have of course no place in modern software, but many programmers can be sometimes a bit lazy.

Indeed. I think for the most part it is true. Especially for OSs However, I have met on numerous occasions programmers who prefer to just use "int" in the code (as opposed to in32, int64, long, double word et. al - there's so many.) and use a compiler directive when compiling for x64 or x32 or even x16 (therefore converting ALL ints to whatever). Seems particularly prevalent when porting. Like you said. Programmers are lazy