From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strings in CINs

I am trying to deal with strings in a CIN within LabVIEW...

When I wire up a String Control to the Code Interface Node in LabVIEW & auto-generate the .c file, I get an argument of the form

LStrHandle *CommandToWrite

OK, the first thing I'm trying to do with this is simply do a DbgPrintf of the string... I've tried a number of different variations of CommandToWrite, **CommandToWrite, *CommandToWrite, etc. but none of them seem to give me out the string I input in LabVIEW...

So my question is how do I (in this case) print out the contents/data of my string in my CIN ?
0 Kudos
Message 1 of 10
(2,937 Views)
The syntax should be

/* print the contents of an LStrHandle (LabVIEW string),
opening the window if necessary */
DbgPrintf("%H", *CommandToWrite);

When you say it isn't working, do you mean that you aren't getting any output (does the window open?), or that it isn't the value you expect?

What version of LabVIEW and what OS are you running on?
0 Kudos
Message 2 of 10
(2,919 Views)
When I say it didn't work, for one usage it crashed LabVIEW, for all the others it opens the Debug window ok but displays garbage/non-printable characters for the value...

When I try this %H usage on my Linux box it crashes LabVIEW with a message:-

LabVIEW caught fatal signal
7.0 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x6

This is the CIN code I'm testing it with... nothing too rocket-science-y, I would have thought 🙂

/* CIN source file */

#include "extcode.h"

MgErr CINRun(LStrHandle *String_In, uInt32 *Integer_In);

MgErr CINRun(LStrHandle *String_In, uInt32 *Integer_In)
{
DbgPrintf("%H\n",*String_In);
DbgPrintf("%d\n",*Integer_In);
return noErr;
}
/* END CIN source file */
0 Kudos
Message 3 of 10
(2,916 Views)
Michael.Johnson;

I think you need to convert the string into a c string first. Try the following (new code in bold. Disclaimer: I haven't check it yet!!):

/* CIN source file */

#include "extcode.h"

MgErr CINRun(LStrHandle *String_In, uInt32 *Integer_In);

MgErr CINRun(LStrHandle *String_In, uInt32 *Integer_In)
{
char cstring[20]=""; /* WARNING: Modify the length of the string to suite your needs */

/* WARNING: You may want to check first if cstring is large enough before performing the next operation */

SPrintf(cstring, "%H", String_In);

DbgPrintf("%H\n",*cstring);
DbgPrintf("%d\n",*Integer_In);
return noErr;
}
/* END CIN source file */


Regards;
Enrique

Message Edited by Enrique on 04-05-2005 11:22 AM

www.vartortech.com
0 Kudos
Message 4 of 10
(2,911 Views)
You don't need to convert to a CStr - DbgPrintf handles LStrHandles.

Could you post your VI and C code for this test? I'm trying to recreate your problem but I am not sure how you are defining the VI so that you get an LStrHandle*. All of my C generated code is only an LStrHandle.

From your post, I assume you are running on Linux but what version of LabVIEW are you using?
0 Kudos
Message 5 of 10
(2,904 Views)
It's Version 7.0 running under Redhat Linux 8...

I've attached the VI & C Code to this Posting...

At present I can access the data doing something like: -

MgErr CINRun(LStrHandle *String_In, uInt32 *Integer_In)
{
int NumChars=0;
char Local_String[256];
LStr *LStrPtr;

LStrPtr = *String_In;
NumChars = LStrPtr->cnt;
strncpy(Local_String,LStrPtr->str,NumChars);
Local_String[NumChars]='\0';
DbgPrintf("%s\n",*String_In);
DbgPrintf("%s\n",LStrPtr->str);
DbgPrintf("%s\n",Local_String);
DbgPrintf("%d\n",NumChars);
DbgPrintf("%d\n",*Integer_In);
return noErr;
}

However, this is messy, so obviously if I can access the LStrHandle directly this would be ideal 🙂
0 Kudos
Message 6 of 10
(2,894 Views)
That explains it. I was wondering why I was getting a different result from you (I was running 7.1 to test this). Under 7.0 I get the same C code you do. However, that is a bug. Check out

http://digital.ni.com/public.nsf/websearch/EA7899C5D74340F886256D9700784C21?OpenDocument

Once you fix that up you should be able to use the Handle and DbgPrintf just fine. Let me know if you still have problems with it after that.
0 Kudos
Message 7 of 10
(2,881 Views)
Excellent... made those changes & yes, DbgPrintf now seems to be working fine.
I still need integers & other numbers passed as uInt32 *Name or whatever though, don't I?

OK, 1 last question so & then I hopefully will be up & running... I want to pass this LStrHandle to a function which is expecting a pointer to a C String i.e the definition in the function parameter listing is char *HostName say, and I want to pass my LStrHandle String_From_LV that I've gotten into my CIN from LabVIEW to this. Is there any neat way of doing this? Can I do it directly? At present I have to copy it to a C String I've created in CINRun() & then pass a pointer to this C String for it to work...

Many Thanks for all the help,

M.J.
0 Kudos
Message 8 of 10
(2,873 Views)
Here's the CIN code I'm currently playing with: -

#include "extcode.h"

MgErr CINRun(LStrHandle String_In, uInt32 *Integer_In);
void Print_String (char *LabVIEW_String);

MgErr CINRun(LStrHandle String_In, uInt32 *Integer_In)
{
Print_String(String_In);
}

void Print_String (char *LabVIEW_String)
{
DbgPrintf("%s",LabVIEW_String);
}

Unfortunately, this crashes LV every time I run it:) But I hope you can get the idea of what I want to do... the function Print_String() takes a pointer to a C string, I can't change that, so I have to format the argument to the Print_String call in my CIN to make it somehow compatible. As I said, I can do this by copying my LStrHandle to a C String in CINRun() & passing that to my sub-function, but is there a neater solution 🙂 ?
0 Kudos
Message 9 of 10
(2,870 Views)
Unfortunately not that I know of. An LStr is like a string in some non-C languages (such as VB) - it is an array of characters with a "hidden" length at the start. It is not NULL terminated. Thus passing it as a C string is going to cause problems. The only thing I know to do is use the LStr API's to get the length and then create your own null-terminated version.
0 Kudos
Message 10 of 10
(2,860 Views)