Hi,
There is a third option:
Use windows lstrcpyn from kernel32.dll. This copies a pointer to mem to a
string, if configured correctlly.
This still stops when a \00 is encountered. So if it stops, add \00 to the
string, add the length of the string (incl. \00) to the pointer, and use the
new pointer to do the same. While doing this, concatinate the returned
strings.
Repeat until satisfied (enough chars have been returned, or a EOF is found.
The EOF can be anything).
Regards,
Wiebe.
"SachaE"
wrote in message
news:50650000000500000037950000-1027480788000@exchange.ni.com...
> Hi,
> there's only two options I can think of, both requiring
> modifications to the DLL.
> Firstly (and easiest) is to return the data in the format of
an array
> of numbers (Unsigned 8 bit). You can then use the byte array to
> string.vi inside LabVIEW to convert it to your desired format. You
> should find that the NULLs (00) then appear correctly inside the
> string - to prove it just put the byte array to string.vi down and
> create the appropriate control and indicator. Fill in a few of the
> array elements with say 65, 66, 00, 67, and 68 and you should see
> (when run) AB CD in the string indicator - if you look at the '/'
> codes view it should then be AB/00CD.
>
> The other option is to replace every NULL inside the .dll's returning
> data to be another character - prefereably one that is never used. The
> downside is that although the data will appear in LabVIEW complete,
> you'll then have to strip out the replacement character before you
> make use of the data.
>
> Hope that helps
>
> S.