🚀 go-pugleaf

csigjb@luxor.latrobe.edu.au () wrote:



>This program should exit such that the screen is clear with the DOS prompt
>in the upper left corner, but no, it exits with a short line of text on the
>first line and then the DOS prompt on the next line. I never (or rarely)
>have these sort of problems with Pascal so why do they continuously crop up
>with C.

Well, I'm not sure why this happens but there is a couple colutions:

The Ugly way:
	Use the borland graphic interface to capture the data on the screen
before anything happens in the program. Then restore the buffer upon
exit. In c++, this can be done using a constructor/destructor. The
only problem is, If you are using Borland, then you have to use their
BGI drivers. THEY SUCK!!!!!!! 

The clean way. Write yourself a cool little routine that stores the
contents of the active page. This can be done with a pointer  that is
assigned an absolute address to video memory and treating it as an
array. Then just use the same array to restore what the screen to it's
original status upon exit. look up 

>PROBLEM 2 :

>const escape=27;
>const cr=13;
>const bs=8;

>while (ch!=cr)
>{
>     .
>     .
>     .
>}

>while (ch!=escape)
>{
>     .
>     .
>     .
>}

>If I replace the 27 with \27' or the 13 with '\13' then these loops don't
>work i.e. an infinite loop results. WHY?

>Also if I want to do somthing like this : puts("\24 \25"); which should
>print the up and down arrows on the screen (ASCII 24 and 25), but no, it
>prints some other ASCII characters. As far as I can tell C has its own
>unique character table, at least for the control characters. WHY?

>Sometimes I wonder whether some one needs to go back an rewrite the damn
>language so that it works sensibly and predictably like Pascal can be
>relied upon to do.

Because when you actually press the esc key, it's ASCII value is 27,
using /27 refers to esc  when using the printf stuff. The /13 is
evaluated in those particular functions but I don';t think they are
evaluated when doing a straight compare. This has happened to me
before. If you do a printf and use /13, you get a CR , but if you read
in a CR, you get 13. Think about it, it's only a byte value and should
be treated as such.