Old-fashioned Style (ASCII/ANSI) & Console Applications in c#

[Martín Marconcini]

Hello there,

I'm writting (or trying to) a Console Application in C#. I has to be
console.
I remember back in the old days of Cobol (Unisys), Clipper and even Basic,
I used to use a program (its name i cannot recall now...) where I designed
the "screen" using this "program" and then saved it into an ASCII file.
(thus, using 'extended' ASCII's like Lines, Corners, etc. and making
screens look nicer and more professional). Then reading a stream of bytes
you "read" the screen and "rendered" (write) it back to the screen.
Nothing compared with the DOOM3 upcoming engine but...

In unisys I could also bind with codes the fields and it's possitions...
bla bla bla... (that was in 1990!)

I've explained it all because I would like to make sure you understand
what is happening to me.

For this console app I am designing I'd like to use either that technique
(which proved to be very simple and useful back in 1990) or something new
(which I don't know and I'm all ears...).
I've found a nice class which uses some api calls and allows me to easyly
change the screen color and cursor position and clear screen and all the
simple utilities you'd love to have for a console app, and reading through
its source code I found out that it appears to use Unicode. But I'd love
to be able to use my technique (unless someone could point me to something
better?) to draw the screens, cuz I'd hate to harcode all the screen
stuff.
The problem I'm experiencing is... back in the '90 I used ASCII
Extended(which doesn't exist really, can I call it ANSI Codes?), but those
128++ ascii codes does not correspond with their unicode counterparts (as
the 1st 128 do). Then if I use an ASCII drawing program (do you remember
TheDraw! for example?) and save a small "box" in ASCII, when I later read
the stream in C# the output is crap...
I wouldn't mention saving the "box" as ANSI (with or without colors)
because there is not Encoder for Ansi under .NET

I use this c# code to read the "ascii file":

// Create the Stream and set its encoder.
FileStream aFile = new FileStream("test.asc",FileMode.Open);
StreamReader sr = new StreamReader(aFile,System.Text.Encoding.ASCII);

string line;
// Read all the stream at once (after all is just "a screen")
line = sr.ReadToEnd();
// Write back to the screen FIXME: output for extended ASCII/ANSI is crap
Console.Write(line);
// Close the Stream
sr.Close();

The output is a typical "extendedASCII" opened with notepad if you know
what I mean. You can guess what the figure is, but the preety thin
single/double lines (just to mention a few) are replaced with accented
chars and other strange simbols. I think that depends upon the CodePage
you have.

I call it here Extended ASCII but the truth is that i'd love to display
ANSI (with colors if possible)... because i understand that Extended ASCII
depends exactly upon the CodePage you are using... is that correct?

It's been a long time since i had to use these words, ANSI, DOS, TheDraw,
etc... back in the BBS era...

The thing is, there is no such Encoding.extASCII... what can I do? What do
you suggest?
Any ncurses lib like in unix environments? (ncurses really helps out
there!)

On the other hand.. everywhere I read, Unicode is "THE" solution for these
matters, so my question would be: is there such thing as TheDraw For
Unicode? So I'd save my "screens" as file.unicode and use the default
encoder for a StreamReader...? This is just an idea (weird)

I'm confused and old fashioned...

Ideas? Comments? Help?

Everything will be appreciated.

thanks in advance, and kind regards!

Martín Marconcini

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Dmitriy Lapshin [C# / .NET MVP]]

Hi Martin,

To the best of my knowledge, C# does not have rich console support. Only
basic I/O such as WriteLine or ReadLine is supported. There are no managed
means to control cursor position,
background/foreground color etc. The only solution I see is to develop a set
of wrapper classes to Windows API console functions (these AFAIR can do
advanced console UI stuff - at least programs such as FAR manager manage to
display such a UI in Windows - and they are true 32-bit apps).

As for Extended ASCII, the problem is indeed with the code page. You should
use the correct encoding to construct a System.IO.StreamReader instance or
convert your screens to Unicode (develop a simple convertor reading ASCII
and producing unicode - or even have Notepad open the source file as ASCII
and save it as Unicode).

P.S. I'd still strongly recommend moving on to Windows Forms uless you are
under pressure to deliver such an old-fashioned application. Windows Forms
of course have they own peculiarities and whims, but designing and
implementing simple GUIs is really easy.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

"Martín Marconcini" <co***@dracula.com.ar> wrote in message
news:op**************@msnews.microsoft.com...

Hello there,

I'm writting (or trying to) a Console Application in C#. I has to be
console.
I remember back in the old days of Cobol (Unisys), Clipper and even Basic,
I used to use a program (its name i cannot recall now...) where I designed
the "screen" using this "program" and then saved it into an ASCII file.
(thus, using 'extended' ASCII's like Lines, Corners, etc. and making
screens look nicer and more professional). Then reading a stream of bytes
you "read" the screen and "rendered" (write) it back to the screen.
Nothing compared with the DOOM3 upcoming engine but...

In unisys I could also bind with codes the fields and it's possitions...
bla bla bla... (that was in 1990!)

I've explained it all because I would like to make sure you understand
what is happening to me.

For this console app I am designing I'd like to use either that technique
(which proved to be very simple and useful back in 1990) or something new
(which I don't know and I'm all ears...).
I've found a nice class which uses some api calls and allows me to easyly
change the screen color and cursor position and clear screen and all the
simple utilities you'd love to have for a console app, and reading through
its source code I found out that it appears to use Unicode. But I'd love
to be able to use my technique (unless someone could point me to something
better?) to draw the screens, cuz I'd hate to harcode all the screen
stuff.
The problem I'm experiencing is... back in the '90 I used ASCII
Extended(which doesn't exist really, can I call it ANSI Codes?), but those
128++ ascii codes does not correspond with their unicode counterparts (as
the 1st 128 do). Then if I use an ASCII drawing program (do you remember
TheDraw! for example?) and save a small "box" in ASCII, when I later read
the stream in C# the output is crap...
I wouldn't mention saving the "box" as ANSI (with or without colors)
because there is not Encoder for Ansi under .NET

I use this c# code to read the "ascii file":

// Create the Stream and set its encoder.
FileStream aFile = new FileStream("test.asc",FileMode.Open);
StreamReader sr = new StreamReader(aFile,System.Text.Encoding.ASCII);

string line;
// Read all the stream at once (after all is just "a screen")
line = sr.ReadToEnd();
// Write back to the screen FIXME: output for extended ASCII/ANSI is crap
Console.Write(line);
// Close the Stream
sr.Close();

The output is a typical "extendedASCII" opened with notepad if you know
what I mean. You can guess what the figure is, but the preety thin
single/double lines (just to mention a few) are replaced with accented
chars and other strange simbols. I think that depends upon the CodePage
you have.

I call it here Extended ASCII but the truth is that i'd love to display
ANSI (with colors if possible)... because i understand that Extended ASCII
depends exactly upon the CodePage you are using... is that correct?

It's been a long time since i had to use these words, ANSI, DOS, TheDraw,
etc... back in the BBS era...

The thing is, there is no such Encoding.extASCII... what can I do? What do
you suggest?
Any ncurses lib like in unix environments? (ncurses really helps out
there!)

On the other hand.. everywhere I read, Unicode is "THE" solution for these
matters, so my question would be: is there such thing as TheDraw For
Unicode? So I'd save my "screens" as file.unicode and use the default
encoder for a StreamReader...? This is just an idea (weird)

I'm confused and old fashioned...

Ideas? Comments? Help?

Everything will be appreciated.

thanks in advance, and kind regards!

Martín Marconcini

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Martín Marconcini]

On Wed, 1 Oct 2003 14:18:55 +0300, Dmitriy Lapshin [C# / .NET MVP]
<x-****@no-spam-please.hotpop.com> wrote:

Hi Dmitry,

To the best of my knowledge, C# does not have rich console support. Only That's what i've seen/heard so far. :(
basic I/O such as WriteLine or ReadLine is supported. There are no
managed
means to control cursor position,
background/foreground color etc. The only solution I see is to develop a
set
of wrapper classes to Windows API console functions (these AFAIR can do
advanced console UI stuff - at least programs such as FAR manager manage That i've solved with ColConsole (www.c-sharp.com), a small lib (source
included) which handles all those issues for me, i can set cursor pos,
clear screen, set back/fore color, fill the back w/ a specific color... it
is great. But, seeking the source, i've found that even when it call some
API funcions, it works with unicode)

to
display such a UI in Windows - and they are true 32-bit apps).
As for Extended ASCII, the problem is indeed with the code page. You
should
use the correct encoding to construct a System.IO.StreamReader instance
or
convert your screens to Unicode (develop a simple convertor reading ASCII
and producing unicode - or even have Notepad open the source file as
ASCII
and save it as Unicode). I'll try that...

P.S. I'd still strongly recommend moving on to Windows Forms uless you

Yep, that's what everybody tells me.. but i'm stubborn... :D
Thanks for your help!
--
MartÃ*n Marconcini