How to call a DLL with a char or a uint8_t

[kennethone]

Good afternoon,

I need to pass an array (image) to my dll.

I was able to successfully do this using 

imageProcess(int **a, ... ){;}

function declaration and using a signed or unsigned 32 bit integer as data type in labview DLL call

However, when I changed my function to either

imageProcess(char **a, ... ){;}     or       
imageProcess(uint8_t **a, ... ){;}

And when  I set the Labview Dll Call data type to    unsigned 8 bit integer

I get a Broken Arrow

With error: The function name specified for this node cannot be found in the library. Right-click the Call Library Function node and select Configure, then choose the correct function name.

I am also using IMAQ ImageToArray to obtain my array and using the ImagePixels(U8) output

Thank you,

[rolfk]

Show your VI, preferably in an older format than 2012. Trying to describe a VI is always going to be very limited, looking at the VI will tell much more and much much quicker.

[kennethone]

It seems that the problem is a much deeper issue of LabView itself. When I re-compile the DLL and do a library call, that library call doesn't recognize that I updated the DLL.

I changed,removed some of the parameters in the DLL and in LabView function call and LabView gives me a broken arrow when it was working before.

How do I update the DLL in LabView so that it recognized that I removed thos entries,

I tried restarting labview but it didn't help

[kennethone]

I figured out the solution:

Under Function Name when double clicking on Call Library Function, if the arguments of the DLL changed at all, you need to click the drop down box and select your function name again, otehrwise LabView gives a broken arrow.

NI really needs to fix this, because it appears as a user data type convention error

[BlueCheese]

If your function is exported with a mangled name (see http://en.wikipedia.org/wiki/Name_mangling) then it is possible that the function's name is changing each time you change the arguments. LabVIEW is de-mangling the names for display purposes, but the linkage into the DLL is using the raw name (you can see listed it in the prototype in the CLN) and is broken each time you change the signature. This behavior is expected because it enforces type safety by breaking the linkage if the type changes.

If you want to force this to not occur, you could export your function with a fixed name from your DLL. How this is done depends on your compiler, but with Microsoft compilers you use a DEF file. (http://msdn.microsoft.com/en-us/library/d91k01sh(v=vs.80).aspx)

Eric

[rolfk]

Another possibility to make functions be unmangled is declaring them as extern "C" like this:

for a single function.

#define LibFunction __declspec(dllexport)

extern "C" MgErr LibFunction MyFunction(uInt8 *);

or:

#define LibFunction __declspec(dllexport)

#if defined(__cplusplus) || defined(__cplusplus__)
  extern "C" {
#endif

LibFunction MgErr MyFunction1(void);

LibFunction MgErr MyFunction2(uInt32);

#if defined(__cplusplus) || defined(__cplusplus__)
}
#endif

for multiple function prototypes.

This will tell the compiler to not mangle the names if it is invoked on a cpp file. And the LibFunction declaration is to declare the function as exported to the compiler, saving you to have to provide a DEF file for that purpuse. Remember that other compilers and platforms might and often do use a different syntax for the export declaration.

And alternative could be:

#define LibFunction(retval) extern "C" retval __declspec(dllexport)

LibFunction(MgErr) MyFunction(uInt8 *);

Also before claiming that there is a huge bug in LabVIEW that needs fixing you should make sure that you understand all in and outs of your C compiler toolchain. Something I wouldn't dare to claim to do!

[BlueCheese]

Just to be clear though, even if you mark it extern "C", depending on your calling convention, the exported name can still change if you change the arguments (unless you use a def file). For instance, stdcall convention mangles the name with the size of the parameters passed to it. In your case, changing from uint8_t to char might not affect the size of the arguments, but if you were to change it to say an int it would.

Eric

[rolfk]

Ah, who is using stdcall nowadays if you control the creation of the DLL too? cdecl is even the default calling convention in Visual C!

But it's a good additional info about the name decoration for functions with stdcall convention. Never really stood still at that thought, but then I never would choose stdcall for my DLLs.