Parameter type from C to Labview

[ritaneves85]

Hello, I have an application on C that interacts with a haptic device and I want to create it in labview. For now, I just want to do a little command to initialize the device "hdInitDevice".
I am using a CLF on labview with the dll for the function, but I'm having trouble with the parameters types.
I think the "arg1" should be an array, since the "nome" is a char.
The return type I don't know.

[rolfk]

Actually it’s better to configure the parameter as a String, Pass as C Data Pointer.

[ritaneves85]

If i choose the type "String" then I can send it as "C string pointer", it does not appear the option of "C data pointer".

And even with this change, it does not work. It gives me the error 1097

[pincpanter]

---

@ritaneves85  ha scritto:

If i choose the type "String" then I can send it as "C string pointer", it does not appear the option of "C data pointer".

And even with this change, it does not work. It gives me the error 1097

---

C String Pointer should be ok. There must be something else wrong.

As a side note, the string to be passed is the name without the quotes.

[rolfk · Accepted solution]

---

@ritaneves85 wrote:

If i choose the type "String" then I can send it as "C string pointer", it does not appear the option of "C data pointer".

---

Semantics. Arrays call it C Data Pointer, Strings apparently C String Pointer. I meant this one. The difference is that since LabVIEW strings are not zero terminated but C Strings are LabVIEW not only passes the internal pointer to the string buffer to the DLL but first makes sure to append a NULL character to the end of the buffer so that the C function sees a valid C string.

---

@ritaneves85 wrote:

And even with this change, it does not work. It gives me the error 1097

---

Check your Calling Convention. LabVIEW defaults to cdecl, since that is the only one available on most non-Windows systems and LabVIEW generally uses that too for its own functions. Windows 32-bit APIs are mostly using stdcall and many other DLL creators follow that lead.

For Windows 64-bit it doesn't matter as there is only one common Calling Convention in user space code, and it is in fact neither stdcall or cdecl but the so called fastcall. 

[JÞB]

I was just going to ask why.  Thanks Rolf

Am I correct to assume whitespace in the ID name value would be problematic?  OneOfTheseDays_I_WillLearnToTolerate_c_stringsNUL 

[pincpanter]

---

@JÞB  ha scritto:

I was just going to ask why.  Thanks Rolf

Am I correct to assume whitespace in the ID name value would be problematic?  OneOfTheseDays_I_WillLearnToTolerate_c_stringsNUL 

---

No. A whitespace is just another respectable non-null character.

[ritaneves85]

It solved the problem, thank you !

[rolfk]

---

@JÞB wrote:

I was just going to ask why.  Thanks Rolf

Am I correct to assume whitespace in the ID name value would be problematic?  OneOfTheseDays_I_WillLearnToTolerate_c_stringsNUL 

---

Not sure where you are heading at. Whitespace is usually the name used for all kind of characters such as character tab, line feed, lne tabulation, form feed, carriage return, space, next line, and no-break space. The last two do not exist in all ANSI codepages as they reside in codepoints >= 128. They are simply valid characters but are generally white space on the paper, with no inkt, toner or whatever being placed.

C only assigns a special meaning to the NULL character. All the rest is simply ANSI defined and for codepoints below 128 also the same in Unicode.