Return boolean from c++ dll to call library function node

[Kathie]

Hi,

I have a c++ dll that has a function inside that returns a boolean value. Is there a way to receive a boolean from a c++ dll and read it in labview?

Thank you,

Kathie

[Mike Ashe]

I believe a boolean from a DLL is actually a 32 bit integer. I don't recall if it is signed or unsigned. Try both and run and look at the number you get out. Should be 0 or 1.

[Kathie]

Thanks for the reply! I tried both and the values stay the same even if they have been changed in the dll. The variable is declared in the c++ code as:

bool touched

I have the library function declared as

unsigned long getTouch(void)

Any more suggestions? Thanks!

K

[LAVA 1.0 Content]

I have a c++ dll that has a function inside that returns a boolean value. Is there a way to receive a boolean from a c++ dll and read it in labview?

Select adapt to type and connect boolean to the input. In this way boolean is passed as unsigned char * (or LVBoolean * which is the same thing) . All the values differing from 0 are regarded as true and 0 is regarded as false. You can also use macros LVTRUE and LVFALSE in the C code. Remember to include "extcode.h" from CIN directory to be able to use the macros and LVBoolean type defenition.

[bsvingen]

Thanks for the reply! I tried both and the values stay the same even if they have been changed in the dll. The variable is declared in the c++ code as:

bool touched

I have the library function declared as

unsigned long getTouch(void)

Any more suggestions? Thanks!

K

I have noticed that if you have different DLLs with the same name in different folders and change between them, Labview does not always change to the correct one. It get stucked with the one it find when you load the vi, even though you manually change to another one. It has happened to me several times (in LV7-7.1), but i'm not sure if it always happends.

Another ting is that you should make the prototype in LV (the "make C code" or something in the DLL call in LV), then you are 100% sure to use correct types.

[Rolf Kalbermatter]

Select adapt to type and connect boolean to the input. In this way boolean is passed as unsigned char * (or LVBoolean * which is the same thing) . All the values differing from 0 are regarded as true and 0 is regarded as false. You can also use macros LVTRUE and LVFALSE in the C code. Remember to include "extcode.h" from CIN directory to be able to use the macros and LVBoolean type defenition.

BOOL in Win32 API nomenclature is really a 32 bit integer while a LabVIEW boolean is an 8 bit integer. In this case it might be a non issue but if you pass it as a function parameter this might be rather important. LabVIEW assuming an 8bit integer might decide to only initialize the lowest significant byte of the 32byte value pushed on the stack leaving the other 24 bits at random. If the DLL expects a Windows BOOL instead and does the standard boolean expression evaluation of only comparing against being non-NULL, you likely will never see the DLL receive a FALSE no matter what you do in LabVIEW.

As far as using signed or unsigned integer for a Boolean does not matter at all. Since a Boolean by definition is either 0 = FALSE or non-0 = TRUE, the signed evaluation does not matter at all.

Rolf Kalbermatter

Thanks for the reply! I tried both and the values stay the same even if they have been changed in the dll. The variable is declared in the c++ code as:

bool touched

I have the library function declared as

unsigned long getTouch(void)

And how does the prototype of the function look, you are trying to call?

Rolf Kalbermatter

[Rexxar]

QUOTE(rolfk @ Jun 12 2006, 09:30 PM)

BOOL in Win32 API nomenclature is really a 32 bit integer while a LabVIEW boolean is an 8 bit integer. In this case it might be a non issue but if you pass it as a function parameter this might be rather important. LabVIEW assuming an 8bit integer might decide to only initialize the lowest significant byte of the 32byte value pushed on the stack leaving the other 24 bits at random. If the DLL expects a Windows BOOL instead and does the standard boolean expression evaluation of only comparing against being non-NULL, you likely will never see the DLL receive a FALSE no matter what you do in LabVIEW.

As far as using signed or unsigned integer for a Boolean does not matter at all. Since a Boolean by definition is either 0 = FALSE or non-0 = TRUE, the signed evaluation does not matter at all.

Rolf Kalbermatter

And how does the prototype of the function look, you are trying to call?

Rolf Kalbermatter

In fact in C++ we have two types bool, the first is BOOL which is a macro in windows.h and has a 32bit ability, another is bool which is a regular type in C++,it's a U8 type. I have tried for several times for these two types in CLF, none is successful, I tried to pass bool using Adapt to Type, it seems to be successfun for only one time.

[Aristos Queue]

QUOTE(Rexxar @ Mar 28 2007, 01:06 AM)

In fact in C++ we have two types bool, the first is BOOL which is a macro in windows.h and has a 32bit ability, another is bool which is a regular type in C++,it's a U8 type. I have tried for several times for these two types in CLF, none is successful, I tried to pass bool using Adapt to Type, it seems to be successfun for only one time.

For bool (the C++ keyword) there is no size standard. The language defines it as a keyword so that the compiler can choose the size that is most optimal for the platform. On most platforms, you can call a function that has a bool parameter by configuring the Call Library Node as if the function had a uInt8, but bool can be larger if that provides better alignment on the platform.

For BOOL, which is fixed as a 32-bit integer I THINK you should be able to configure the Call Library Node as if the function had an int32.

In both cases, use the "not equals zero" primitive to get the boolean evaluation. DO NOT use "equals one" -- true is defined as any non-zero value, and you may get values back that are other than zero or one.