Jump to content

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


Recommended Posts

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

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
  • 9 months later...

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.