Write Extended ASCII Characters to a file

[BrokenArrow]

Hello all!

I need to write, to a txt file, some of the extended ascii characters, specifically the "box drawing" type such as alt+203, alt+204, etc. How is that done in LabVIEW? I've done it with unicode (by writing FFFE 6625 for example, to get one of the characters), but as you know, the file resulting Unicode becomes useless to LV when you read it and parse for data later.

Thanks,

Richard

(lv 8.2.1)

[eaolson]

QUOTE(BrokenArrow @ Oct 2 2007, 11:13 AM)

I need to write, to a txt file, some of the extended ascii characters, specifically the "box drawing" type such as alt+203, alt+204, etc. How is that done in LabVIEW? I've done it with unicode (by writing FFFE 6625 for example, to get one of the characters), but as you know, the file resulting Unicode becomes useless to LV when you read it and parse for data later.

You can write the extended characters just as you would a normal character. The problem might be that Windows and DOS use different character encodings. If you have a file containing extended characters and open it with Notepad, you'll see lots of vowels with umlauts and accents. If you open the same file in a DOS window, you see the box-drawing characters. Character 203 (0xCB) is a capital E with an umlaut in Windows, but displays as a double-walled box character in DOS. You can use a string constant with the slash display or hex display to get to the extended characters without worrying about how they are displayed in LabVIEW.

[TobyD]

QUOTE(BrokenArrow @ Oct 2 2007, 09:13 AM)

Hello all!

I need to write, to a txt file, some of the extended ascii characters, specifically the "box drawing" type such as alt+203, alt+204, etc. How is that done in LabVIEW? I've done it with unicode (by writing FFFE 6625 for example, to get one of the characters), but as you know, the file resulting Unicode becomes useless to LV when you read it and parse for data later.

Thanks,

Richard

(lv 8.2.1)

╦

╩ don't think LabVIEW supports the characters you are trying to use. I attempted a similar thing a while back and never came up with a way to do it. It seems like the characters automatically get converted to something that LV can handle.

Edit: I looked into it some more and it looks like the box characters you are trying to write (╦╔╚ etc) are actually Unicode characters and not extended ASCII. The true extended ASCII characters appear to be supported.

[eaolson]

QUOTE(TobyD @ Oct 2 2007, 03:01 PM)

╦

╩ don't think LabVIEW supports the characters you are trying to use. I attempted a similar thing a while back and never came up with a way to do it. It seems like the characters automatically get converted to something that LV can handle.

Edit: I looked into it some more and it looks like the box characters you are trying to write (╦╔╚ etc) are actually Unicode characters and not extended ASCII. The true extended ASCII characters appear to be supported.

The problem here is that there is no such thing as "extended ASCII." ASCII is a fairly well-defined standard that defines the association of characters for the numbers 0-127 (7-bit). Everyone is in agreement that 97 means an "a". When you extend this to 8-bits, the numbers 128 and above are not as well agreed upon. Depending on what character encoding you're using, the glyphs displayed for 128-255 will be different. The underlying number is still the same.

My installation of Windows seems to be using Windows-1252, where the high byte characters are primarily accented letters. DOS used code page 437, where the high byte characters are the box-drawing characters without with Nethack would not be possible. So you can write high-byte characters to a file with the usual file VIs, but they will only display as the box-drawing glyphs in certain situations.

[BrokenArrow]

Thanks for all the response. Yep, this seems like more trouble than it's worth. The customer is used to an old DOS-based text file that had those box characters. The way I got LabVIEW to do it was to send FFFE 6625 and I got ╦. BUT, when it writes the "txt" file, and you open it in notepad, sure enough it looks fine, but it says it's Unicode encoded. Try to read that file BACK into LabVIEW and it's SOL.

Thanks for the education, I didn't know "extended ASCII" was so softly defined, since I've been using those alt+200 type things successfully since 1986 in DOS, I just figured it would work the same way in LV.

-Richard

[TobyD]

QUOTE(eaolson @ Oct 2 2007, 01:35 PM)

without with http://www.nethack.org/' target="_blank">Nethack would not be possible

I had forgotten all about nethack! I can't wait to get home and play it...Ahhh how the years fly by.

[Rolf Kalbermatter]

QUOTE(BrokenArrow @ Oct 2 2007, 03:55 PM)

Thanks for all the response. Yep, this seems like more trouble than it's worth. The customer is used to an old DOS-based text file that had those box characters. The way I got LabVIEW to do it was to send FFFE 6625 and I got ╦. BUT, when it writes the "txt" file, and you open it in notepad, sure enough it looks fine, but it says it's Unicode encoded. Try to read that file BACK into LabVIEW and it's SOL.

Thanks for the education, I didn't know "extended ASCII" was so softly defined, since I've been using those alt+200 type things successfully since 1986 in DOS, I just figured it would work the same way in LV.

-Richard

Those box characters did even in DOS only show up if one didn't use some other codepage for displaying. Now caused codepages in DOS such a pain that they were not as often used so you could usually get away with this, but Windows 3.1 extended the codepage idea greatly and made serious use of it before they implemented 16bit Unicode support in Windows NT and ported it back for Windows 95. Only with Unicode was it possible to have support for displaying different languages at the same time without constantly having to switch codepages. Another means for that was MBCS (multibyte character encoding)which is what LabVIEW uses itself to support eastern languages in its localized versions but that is quite a painful standard as a character can have a varying number of bytes, with certain codes reserved to indicate the switch to a different "codepage".

While the display of the lower half of ASCII characters is well defined, what is displayed for the higher half depends on the viewer and its interpretation. If displayed in a Windows (and LabVIEW) control you can also get away with setting them to certain fonts as every font has an implicit codepage for its first 256 characters.

Rolf Kalbermatter

[BrokenArrow]

.... If displayed in a Windows (and LabVIEW) control you can also get away with setting them to certain fonts ......

Rolf Kalbermatter

Indeed. But getting everyone who may look at the data to set Notepad or Wordpad, et.al. to a certain font is a leap. I just made a text file that looks great in Courier (width defined characters), good (not great) in Arial, but switch to Times' and it's hosed up. I installed our Reports Toolkit last night with much hesitation, and I'll probably end up using Excel for the "human viewable" report.

-Richard

(p.s. On a side note, if you use the Excel VI's and want to make an EXE, remember to include the proper Dynamic VI's in your build! :headbang: )