Problem Reading Text File

[scottrod]

CVI programmer for many years, but it's been a while. Trying to read in a text file that comes up fine in say NotePad. The first line of text in the file is:

All temperatures in °F.

If I use the scan function, say:

static char  cdum[2048];

ScanFile (DataFile, "%s>%s", cdum); I get these results:

cdum[0] is -2

cdum[1] is 65 (which is the ASCII "A" character)

The rest of cdum is all zeros.

In a hex editor in decimal display grouped by bytes, the line is:

255 254 65 0 108 0 108 0 32 0 116 0 101 0 109 0 112 0 ... such that the display looks like

ybA.l.l. .t.e.m.p.e.r.a.t.u.r.e.s. .i.n. .°.F...

So I get that the Scan function is seeing the start character, then pulling the 65 out and putting it into the cdum[1] location, then hits the 0 character and exits the Scan function like it found an end-of-line. Trying to read in the entire line and subsequent data line which is float data, but doesn't matter, I can figure that our after I get over the initial problem above.

Can someone help me with this? I have no problem reading in regular text files, but this one is like it's grouped in words rather than bytes. Have tried a bunch of different Scan function source and target modifiers [xt0, w#, etc] but nothing seems to be working.

Data file attached.

Thanks -

Scott

[Wolfgang · Accepted solution]

Hi,

I have downloaded your file, it opened in Excel due to its extension and the settings on my computer. I then wanted to save it as a regular text file to see it in Notepad and to read it with a simple C program. When doing so, Excel told me: Some features in your workbook might be lost if you save it in Unicode text.

This is compatible with your observation of 16 bit data.

Unfortunately LabWindows/CVI does not support the Unicode character set and library functions operate on 8 bit characters only.

So i would suggest to convert your file to 8 bit characters; you also may support the quest for Unicode support in CVI here

[scottrod]

Thanks Wolfgang. I was unfamiliar with the Unicode set, but it makes sense now.

Will find a workaround.