I'm trying to call a LV DLL from within LV (seperate project). Once the DLL has been comppiled I'm using the Import Shared Library to create the node.
However when I try this I get an error message with the import that appears to have trouble with LVBoolean and int32_t.
I've created a simple DLL (adds a DBL to an INT 32 and creates a Bool when the sum is > 0).
Compiling this DLL and trying to import it has the same issue.
I think the first step is to provide the exact error message you are getting.
First question is, why are you trying to call a LabVIEW-built DLL from within a VI? There are much better ways to load external LabVIEW code. If you need to call this DLL from other languages as well, then you should get rid of the LabVIEW-specific datatypes (the error clusters).
The main cause of the error you're seeing is buried towards the bottom - it can't find the "extcode.h" header that defines the missing types LVBoolean and int32_t. You can add the path to the folder containing that file (it's in cintools, in your LabVIEW install folder) but you may still get errors, which you could probably resolve with an appropriate combination of preprocessor definitions. However, an easier solution is to modify the header file for your DLL. Remove the line that includes extcode.h, replace LVBoolean with "char", and replace int32_t with "int". Those are the same definitions that the header file would define. This does mean LabVIEW will create the datatypes with U8 instead of booleans, which you can replace yourself with a boolean after importing.
This does mean LabVIEW will create the datatypes with U8 instead of booleans, which you can replace yourself with a boolean after importing.
Except that the Call Library Node doesn't allow for configuration of an explicit boolean type (for obvious reasons as there is no standardized boolean datatype in C before C11 and even then the standard says nothing about if it should be a byte or the prefered integer size for the current platform or anything else). LabVIEW then uses Adapt to Type instead, which forces the skalar parameter to be always passed by pointer!
Most simple solution is to still use an explicit integer that is properly sized and convert between the LV Boolean and the integer on the diagram.
LabVIEW then uses Adapt to Type instead, which forces the skalar parameter to be always passed by pointer!
Coincidentally that would be the correct behavior here since the boolean parameter acts as an output and so needs to be passed by pointer... but of course you're correct that I oversimplified, and that forcing the use of a integer consistently would be better.