Re: Clear Screen

Re: Clear Screen

[Larry Kilgallen]

In article <330D0C26.6331@videotron.ca>, Christian Lebeau <lebeauc@videotron.ca> writes:

> I am just beginning to learn ADa, so fare i was not able to find how to
> do a clear screen!!!
> Can anyone tell me how to do a simple clear screen

Since you do not specify any particular:

	Ada Compiler, Operating System, Screen

I will presume:

	DEC Ada V2, VAX VMS V5.4, VT100

In which case you could call the SCR library with request
type SCR$C_ERASE_PAGE.

With Ada 95, things are less dependent upon your compiler and
operating system, but they have not improved at all with regard
to having the compiler on the development machine guess what
model of screen (character cell, X-windows, etc.) will be on
the production machine.

Larry Kilgallen

Re: Clear Screen

[Albert K. Lee]

In article <1997Feb21.115525.1@eisner>, Larry Kilgallen wrote:
>In article <330D0C26.6331@videotron.ca>, Christian Lebeau <lebeauc@videotron.ca> writes:
>
>> I am just beginning to learn ADa, so fare i was not able to find how to
>> do a clear screen!!!
>> Can anyone tell me how to do a simple clear screen
>
>Since you do not specify any particular:
>
>	Ada Compiler, Operating System, Screen
>
>I will presume:
>
>	DEC Ada V2, VAX VMS V5.4, VT100
>
>In which case you could call the SCR library with request
>type SCR$C_ERASE_PAGE.

I've been using Ada for a semester now and I don't understand that.
The original poster stated he was a beginner, so some more sane
presumptions might be in order:

	GNAT 3.0x, MS-DOS or UNIX, VT100 (or MSDOS with ANSI.SYS loaded)
	(not sure if this'll work on a Mac)

in which case you'd 'with' the Ada.Text_IO package and ...

	Ada.Text_IO.Put (Character'Val(27) & "[2J");

to clear the screen (Character'Val(27) is the escape char), then

	Ada.Text_IO.Put (Character'Val(27) & "[H");

to move the cursor to the upper-left corner of the screen.

Re: Clear Screen

[Tom Moran]

for i in 1 .. 50 loop
  text_io.put_line(" ");
end loop;
-- would probably work on most systems.

Re: Clear Screen

[Tom Moran]

Learn something new every day department - Text_IO.New_line will take a
count parameter, so
  Ada.Text_IO.New_Line(50);
ought to clear a 'glass teletype' screen.

Re: Clear Screen

[Jean-Etienne Doucet]

In article 29FA@bix.com, Tom Moran <tmoran@bix.com> () writes:
| for i in 1 .. 50 loop
|   text_io.put_line(" ");
| end loop;
| -- would probably work on most systems.


Depending upon which computer I'm using, the following bits work OK
or not:

on the Sparc, Ada.Text_IO.New_Page does the work;

on a PC, I use the escape sequence:
	Ada.Text_IO.Put (Character'Val(27) & "[2J");

Good luck.

JED.

Re: Clear Screen

[Robert Dewar]

JED said

<<on a PC, I use the escape sequence:
        Ada.Text_IO.Put (Character'Val(27) & "[2J");

Good luck.>>

This is the second person to write Character'Val(27) rather than the
much clearer Ascii.ESC! Generally you always want to reference control
characters by name rather than by mysterious constants. Actually better
style is

    Clear_Screen : constant String := Ascii.ESC & "[2J";


	...
     Put_Line (Clear_Screen);

Naming constants is  fundamental technique for making programs more
readable!

Re: Clear Screen

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
  "This is the second person to write Character'Val(27) rather than the
   much clearer Ascii.ESC! "

Maybe you could explain why the perfectly reasonable and standard use
of Ascii.ESC, Ascii.TAB etc has been declared obsolete?

Using Latin_1 requires withing Ada.Characters.Latin_1 and using or
renaming it or its parent in every module that wants to use one of the
standard and well-known Ascii values. This makes it harder/more work
to use the constants, so novice users (the majority) will be unlikely to 
use Latin_1 when they just need that @$#%^& value for a horizontal tab,
linefeed or escape.

In many cases it is better to use the Standard.Ascii package than
the Ada.Characters.Latin_1 package anyway. When I want to use ANSI
escape sequences like the clear screen in the example, I just 
want to use the named ASCII characters, since I cannot assume the 
terminal uses the Latin-1 character set.

Also when I write Ascii.LF everybody knows what I mean, but when I
write Ada.Characters.Latin_1.LF it might not be clear I'm just using
the Ascii linefeed character. IMHO using Latin_1 on a system that 
doesn't support Latin_1 makes no sense.

Regards,
   Geert
-- 
--  E-Mail: geert@sun3.iaf.nl    
--    `` If trainstations are places where trains stop, 
--	 then what are workstations? ''

Re: Clear Screen

[Robert Dewar]

Geert asks

<<Maybe you could explain why the perfectly reasonable and standard use
of Ascii.ESC, Ascii.TAB etc has been declared obsolete?>>

because the referenced standard is obsolete. You know what Ascii means
to you, but the standards world does not. This standard has been obsoleted
by the standard referenced in the Latin-1 package.

So from a formalistic point of view there was an argument that this
package was no longer appropriate so it was put in Annex J (we could
not actually remove it because of compatibility issues).

I argued strongly against the whole idea of Annex J, but I lost (and
surprisingly, I was in a small minority here. But I let it go because
this is a documentation issue only!

The features in annex J are fully supported in Ada 95, and are tested
by the ACVC suite, and must be fully supported in all Ada 95 compilers.
They may be used freely in Ada 95 programs -- some people may feel for
aesthetic reasons that they want to avoid the use of annex J features,
but that's a bed they make for themselves.

If you feel, as I certainly do, that it makes more sense to write Ascii.LF,
then to with the Latin-1 package -- this incidentally is especially true
if you are allergic to use clauses -- then go ahead and write Ascii.LF.

Sure, there are some people who harbour the fantasy that the annex J
features will be eliminated in Ada 0X (these must be the same people
who thought the ALTER verb could be removed from COBOL-8X) but in practice
the compatibility argument will be *stronger* next time around, not
weaker, so these features are not about to disappear!

Re: Clear Screen

[Norman H. Cohen]

Robert Dewar wrote:

> The features in annex J are fully supported in Ada 95, and are tested
> by the ACVC suite, and must be fully supported in all Ada 95 compilers.
> They may be used freely in Ada 95 programs -- some people may feel for
> aesthetic reasons that they want to avoid the use of annex J features,
> but that's a bed they make for themselves.

"Deprecated features" are listed in the most recent COBOL, Fortran, and
Ada standards.  I think Robert is correct in identifying deprecation as
an aesthetic issue.  It's basically a form of disclaimer by the
designers of a language revision, saying, "This construct violates MY
aesthetics.  If I were starting from scratch, I would never of dreamt of
including this feature, but since I have to maintain upward
compatibility, we're stuck with it.  But look at how beautiful the
language would be if I could remove these legacy features!"

Often, the fact that a language feature is deprecated means that there
is now a better way available to accomplish the same result.  However,
if a programmer feels a compelling need to use the old feature in a
particular situation, he ought to feel free to do so.

(Concerning the ASCII package, I would take the trouble in new programs
to write

   with Ada.Characters.Latin_1; use Ada.Characters;

This allows me to write Latin_1.Esc rather than ASCII.Esc, and, more
important, it allows me to write things such as
Latin_1.Registered_Trade_Mark_Sign.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Clear Screen

[Keith Thompson]

In <3316EFA0.7970@watson.ibm.com> "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
[...]
> (Concerning the ASCII package, I would take the trouble in new programs
> to write
> 
>    with Ada.Characters.Latin_1; use Ada.Characters;
> 
> This allows me to write Latin_1.Esc rather than ASCII.Esc, and, more
> important, it allows me to write things such as
> Latin_1.Registered_Trade_Mark_Sign.)

This will also make any other declarations within Ada.Characters visible.
(It happens that the only such declaration is the child package
Ada.Characters.Handling, and that only if you "with" it.)

If that's what you want to do, that's fine.  Another way to do this is

   with Ada.Characters.Latin_1;
   ...
   package Latin_1 renames Ada.Characters.Latin_1;

(I'm not trying to start another use clause flame war, just pointing
out an alternative.)

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"Humor is such a subjective thing." -- Cartagia

Re: Clear Screen

[Robert Dewar]

<<This will also make any other declarations within Ada.Characters visible.
(It happens that the only such declaration is the child package
Ada.Characters.Handling, and that only if you "with" it.)>>

And that presumably is what you want, if you with it, or are you recommending
that the single use clause be replaced by two of your renamings in this case?
:-)

Re: Clear Screen

[Keith Thompson]

In <dewar.857447446@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> <<This will also make any other declarations within Ada.Characters visible.
> (It happens that the only such declaration is the child package
> Ada.Characters.Handling, and that only if you "with" it.)>>
> 
> And that presumably is what you want, if you with it, or are you recommending
> that the single use clause be replaced by two of your renamings in this case?
> :-)

The original discussion mentioned only Ada.Characters.Latin_1.  A use
clause for Ada.Characters makes Latin_1 directly visible, but it can
have other side effects (especially if the implementation provides other
children of Ada.Characters, like GNAT's Wide_Latin_1).

One argument in favor of the renames, in this particular case, is that
the name Latin_1 is far less ambiguous than Handling.

As I said, I'm not recommending anything, just pointing out alternatives.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"Humor is such a subjective thing." -- Cartagia

Re: Clear Screen

[Robert I. Eachus]

   RKBD said:

  > I argued strongly against the whole idea of Annex J, but I lost (and
  > surprisingly, I was in a small minority here. But I let it go because
  > this is a documentation issue only!

    (And I lost on one in the formal vote--pragma Elaborate--but won
later when the Development Team actually checked out the issue.  My
guess is that in about 30% of the cases where pragma Elaborate
actually needed, it can't be replaced by Elaborate_Body or
Elaborate_All.  But I suspect the real reason it was left in Chapter
10 was that it only requires a few words there. ;-)

  > The features in annex J are fully supported in Ada 95, and are tested
  > by the ACVC suite, and must be fully supported in all Ada 95 compilers.
  > They may be used freely in Ada 95 programs -- some people may feel for
  > aesthetic reasons that they want to avoid the use of annex J features,
  > but that's a bed they make for themselves...

  > Sure, there are some people who harbour the fantasy that the annex
  > J features will be eliminated in Ada 0X (these must be the same
  > people who thought the ALTER verb could be removed from COBOL-8X)
  > but in practice the compatibility argument will be *stronger* next
  > time around, not weaker, so these features are not about to
  > disappear!

    There are SOME Annex J features which will probably disappear next
time around: the allowed substitution characters and the chapter 13
stuff (with the possible exception of interrupt entries).  But some of
the stuff there, including package Ascii and the package renamings, will
probably be around in Ada 3x.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Clear Screen

[Robert Dewar]

Robert Eachus said

<<(And I lost on one in the formal vote--pragma Elaborate--but won
later when the Development Team actually checked out the issue.  My
guess is that in about 30% of the cases where pragma Elaborate
actually needed, it can't be replaced by Elaborate_Body or
Elaborate_All.  But I suspect the real reason it was left in Chapter
10 was that it only requires a few words there. ;-)

>>


Rober notes

The history here is that we found it was impossible to build the GNAT
runtime without the use of pragma Elaborate. I investigated carefully,
and sent the exact examples into the vr list, and when we looked into
them they were indeed reasonable.

Nevertheless the estimate of 30% is *way* too high. This is not a guess
it is based on actual observations of the number of times that pragma
Elaborate is used, and could be replaced by Elaborate_All in the GNAT
test suite.

Robert Eachus said

<<There are SOME Annex J features which will probably disappear next
time around: the allowed substitution characters and the chapter 13
stuff (with the possible exception of interrupt entries).  But some of
the stuff there, including package Ascii and the package renamings, will
probably be around in Ada 3x.

>>

That's exactly what people said about ALTER in the context of the COBOL 74
standard (they were sure it would be removed next time around). People who
make such statements greatly underestimate the force of compatibility
arguments from legacy code. I will bet anyone who cares to take the bet
that none of the Annex J features will disappear from the next version
of Ada. I note in advance that of course I will argue against their
removal regardless of whether anyone takes up this bet. We are talking
about a couple of minor features here that are trivial to implement. It
is inconceivable to me that the designers of the next version of Ada
would introduce gratuitious non-upwards compatibilities by trying to
remove them!

Re: Clear Screen

[Keith Thompson]

In <dewar.856916794@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
[...]
>     Clear_Screen : constant String := Ascii.ESC & "[2J";

On a more or less VT100-compatible terminal or emulator, the sequence
ESC [ 2 J will clear the screen without moving the cursor.  No problem
if that's what you want, but you usually want to move the cursor to the
upper left corner of the screen (window, whatever).

>      Put_Line (Clear_Screen);

And, of course, this will move the cursor down one line after clearing
the screen.

This might be closer to what you want:

    Clear_Screen : constant String := Ascii.ESC & "[H" & Ascii.ESC & "[2J";
    ...
    Put(Clear_Screen);

If the lack of a newline causes buffering problems, you might consider
writing to Standard_Error and/or calling Ada.Text_IO.Flush.

If you're on a Unix system and you may be using a non-VT100-compatible
terminal (unlikely these days), you might want to do something like this:

   with Interfaces.C;
   with Ada.Text_IO;
   procedure Clear_Screen is
      function System(S: String) return Interfaces.C.Int;
      pragma Import(C, System, "system");
      Command : constant String := "clear" & Ascii.Nul;
      Result : Interfaces.C.Int;
      use type Interfaces.C.Int;
   begin
      Result := System(Command);
      if Result /= 0 then
	 Ada.Text_IO.Put_Line
	    ( Ada.Text_IO.Standard_Error,
	      "clear failed, result = " & Interfaces.C.Int'Image(Result));
      end if;
   end Clear_Screen;

though it's likely to be inefficient.

If you're using an Etch-A-Sketch (R) compatible display, you need to
print a message asking the operator to turn it upside-down.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"Humor is such a subjective thing." -- Cartagia

Re: Clear Screen

[Robert I. Eachus]

In article <dewar.857270376@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > I will bet anyone who cares to take the bet that none of the Annex
  > J features will disappear from the next version of Ada...It is
  > inconceivable to me that the designers of the next version of Ada
  > would introduce gratuitious non-upwards compatibilities by trying
  > to remove them!

   It is very conceivable to me that say Interrupt Entries will be
supported by no validated implementations when the next major revision
occurs, and that they would be removed on that basis.  (It is also
conceivable that some of the real-time standards and groups will keep
it viable.)  Many other chapter 13 features in Annex J can be easily
converted to legal Ada 95 constructs based on syntax alone.  Those
cases can be moved to a (virtual) preprocessor.

   During the entire time I worked at Honeywell, Cobol 8X was being
held hostage by the Alter verb, so I remember the problem well.  But
the issue there was actually putting something on the deprecated
features list, not removing it once it showed up.  I could point on
the other hand to moving non-signficant spaces to the Fortran
deprecated features list--there was a feature that deserved to die.
(OTOH, I was sorry to lose the "three way if" of Fortran I.)



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Clear Screen

[Robert Dewar]

Robert Eachus said

<<   It is very conceivable to me that say Interrupt Entries will be
supported by no validated implementations when the next major revision
occurs, and that they would be removed on that basis.>>

It may be conceivable to you, but it is just wrong! (already there are
compilers which I guess must seem inconceivable -- they support this
useful feature!)

Re: Clear Screen

[Keith Thompson]

In <330FE569.29FA@bix.com> Tom Moran <tmoran@bix.com> writes:
> for i in 1 .. 50 loop
>   text_io.put_line(" ");
> end loop;
> -- would probably work on most systems.

A few points:

1. Text_IO.Put_Line(" ") puts an extraneous space character on each line.
   The simpler Text_IO.New_Line doesn't.

2. As someone else mentioned, Text_IO.New_Line takes a count parameter,
   which defaults to 1.  Thus, Text_IO.New_Line(50) is equivalent to
   the above loop.

3. This will leave the cursor at the bottom of the screen, which is
   probably not what you want.

4. It won't work in the 60-line window in which I'm composing this message.
   For a 24-line window or terminal, 50 newlines is excessive.

5. For Ada 95, you probably want to refer to Ada.Text_IO (though a
   library-level renaming called Text_IO is provided for compatibility).

If you know you're on a more or less VT100-compatible terminal or emulator
(most of them are these days), there's a particular character control
sequence that will clear the screen and home the cursor:

   <escape>[H<escape>[2J

If you're on a Unix system, you can use interface to system() and invoke
the /usr/bin/clear command, though this is likely to be slow.  Or you
can interface to the termcap, terminfo, or curses library; I don't know
of a commonly available Ada binding for any of these.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"Humor is such a subjective thing." -- Cartagia

Re: Clear Screen

[Robert Dewar]

Albert Lee said

<<in which case you'd 'with' the Ada.Text_IO package and ...

        Ada.Text_IO.Put (Character'Val(27) & "[2J");

to clear the screen (Character'Val(27) is the escape char)>>


I think Albert's guess is indeed more likely to be correct. Assuming that
a beginner is using the DEC compiler is probably not realistic. But the
above code is convoluted, Use Ascii.ESC instead:

        Ada.Text_IO.Put (Ascii.ESC & "[2J");

or, if you are in a frightfully politically correct mode (Ascii.ESC is
another of those very useful Ada features which the designers put in
Annex J for no good reason), then you can add a context clause for
Ada.Characters.Latin_1 and use Ada.Characters.Latin_1.Esc instead of
Ascii.ESC (the latter is in practice far more convenient, since it
is shorter to write, and declard in Standard).

Re: Clear Screen

[Thomas Koenig]

In comp.lang.ada, Christian Lebeau <lebeauc@videotron.ca> wrote:

>I am just beginning to learn ADa, so fare i was not able to find how to
>do a clear screen!!!

This is very system-dependent; if your program runs in batch mode or
in a windowing system, the concept of a "screen" does not even apply.

If you're running on a Unix system, most portable way is to interface
to the curses routines.  See clear(3).
-- 
74 a3 53 cc 0b 19

Re: Clear Screen

[bill]

well just my $.02 on this subject is..i made a screen package which would 
handle the clearing of the screen and moving my cursor around to whereever on 
the screen i wanted it.   the package will also provide a beep(on some systems 
:O)..just not my home pc..but on a VAX  vt100 terminal it does..

good luck

the spec code is...

package screen is

height :constant integer :=24;
width :constant integer :=80;

subtype d is integer range 1..height;
subtype w is integer range 1..width;

procedure beep;
procedure clearscreen;
procedure gotoyx (y: d; x:w);

end screen;


then the package body is

with text_io;
use text_io;
with ada.integer_text_io;
use ada.integer_text_io;
package body screen is

procedure beep is
begin
        put("ascii.bel");
end beep;

procedure clearscreen is
cs :constant string:=(character'val(27) & "[2J");
begin
        put_line(cs);
end clearscreen;

procedure gotoyx (y:d;x:w) is

begin
text_io.put(item=>ascii.esc);
text_io.put(item=>'[');
my_int_io.put(y,width=>1);
put(item=>';');
my_int_io.put(x,width=>1);
put(item=>'f');
end gotoyx;

end screen;




Bill Rawlinson

Re: Clear Screen

[Marin David Condic, 561.796.8997, M/S 731-93]

"Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG> writes:
>   It is very conceivable to me that say Interrupt Entries will be
>supported by no validated implementations when the next major revision
>occurs, and that they would be removed on that basis.  (It is also
>conceivable that some of the real-time standards and groups will keep
>it viable.)  Many other chapter 13 features in Annex J can be easily
>converted to legal Ada 95 constructs based on syntax alone.  Those
>cases can be moved to a (virtual) preprocessor.
>
    Would one practical solution be to throw the features out, but
    insist that compilers maintain an "Ada95 Switch" which makes them
    available for the people who still might need upward
    compatibility? Then after "Ada0x" is superseded by "Ada1x", the
    "Ada95 Switch" becomes invalid - thus providing users plenty of
    time to migrate their code. The advantage is that the features
    aren't really there for the programmers building "Ada0x" code, but
    you haven't hurt those still maintaining Ada95 code.

    I'm pretty sure that Gnat has an "Ada83 Switch" (never had cause
    to use it) which restricts it to Ada83 for those who might have an
    upward compatibility problem. Seems like this is a useful
    compromise.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Airplanes are interesting toys but of no military value."

        --  Marechal Ferdinand Foch, Professor of Strategy, Ecole Superieure
            de Guerre.
===============================================================================

Re: Clear Screen

[Robert Dewar]

One more point about obsolescent features. In my experience, language
designers tend to have far too little appreciation of the difficulty
of modifying code to deal with incomaptibilities. I often here statements
like: well it is easy to go through the code and do xxx. The fact is that
nothing is easy when you are dealing with millions of lines of code.

Ada 95 ended up consierably more upwards compatible than it might have
been if we followed earlier suggestions, and that is definitely a good
thing!

Re: Clear Screen

[Larry Kilgallen]

In article <dewar.857654191@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> One more point about obsolescent features. In my experience, language
> designers tend to have far too little appreciation of the difficulty
> of modifying code to deal with incomaptibilities. I often here statements
> like: well it is easy to go through the code and do xxx. The fact is that
> nothing is easy when you are dealing with millions of lines of code.

Each year I talk to a different class of 100 or so folk from different
companies, and my polling indicates that about 10% are running business
applications where nobody left at the company knows the language used
to implement that application.  When the time comes that someone has
to reach in and change 2 digit years to 4 digit years, it would be very
unsafe to force them to change other parts of the program just because
the compiler that runs on the current version of the operating system
does not support the old dialect.

Larry Kilgallen

Re: Clear Screen

[Robert Dewar]

Larry wrote:

<<Each year I talk to a different class of 100 or so folk from different
companies, and my polling indicates that about 10% are running business
applications where nobody left at the company knows the language used
to implement that application.  When the time comes that someone has
to reach in and change 2 digit years to 4 digit years, it would be very
unsafe to force them to change other parts of the program just because
the compiler that runs on the current version of the operating system
does not support the old dialect.>>

Very nice (and timely!) example :-)

Re: Clear Screen

[Robert Dewar]

Marin said

<<    Would one practical solution be to throw the features out, but
    insist that compilers maintain an "Ada95 Switch" which makes them
    available for the people who still might need upward
    compatibility? Then after "Ada0x" is superseded by "Ada1x", the
    "Ada95 Switch" becomes invalid - thus providing users plenty of
    time to migrate their code. The advantage is that the features
    aren't really there for the programmers building "Ada0x" code, but
    you haven't hurt those still maintaining Ada95 code.>>

This is not worth the effort, because you would still have to formally
define the old features. Note that in Ada 95, we eliminated the old
Ada 83 attributes, not because we expected compilers not to support them --
any reasonable Ada 95 compiler *will* support them -- certainly GNAT does, 
but because it would have been too much effort to explain in Ada 95
terms what they meant.

In practice Annex J is such a small collection of such small features,
that it is simply not worth introducing incomaptibilities by trying
to get rid of them. You get rid of things to simplify the language or
to clean it up, but in this case, the simplication and clean up is
minuscule in the total scale of things anyway.

Annex J ends up being little more than a comment by the designers on
what they felt they would have liked to leave out. A lot of people
disagree with the choice, including me, but I really don't care to
argue the point strongly, since Annex J features are as much a part of
the language as anything else.

As I mentioned before, the experience with ALTER in COBOL 8X should
show just how hard it is to remove features. In this case the COBOL
committee was pretty much unanimous in agreeing that this feature
should be removed, but a large insurance company (name withheld :-)
threatened to sue ANSI and the individual members of the committee
if they took this action, on the grounds that there were commercial
interests represented on the committee which were trying to destroy
the integrity of their legacy code -- ALTER stayed in :-)

Clear Screen

[Brian Hyatt]

Is there another way to clear the screen in Ada?  I know about:
 new_line(25) and put(ansi esc sequence).  I would use the ansi esc
sequence but, what if the computer I execute my program on doesnt have
an ansi driver loaded?    Thanks in advance

Re: Clear Screen

[Albert K. Lee]

On Sun, 23 Mar 1997 13:03:16 -0600, Brian Hyatt <bhyatt@unaalpha.una.edu> wrote:
>Is there another way to clear the screen in Ada?  I know about:
> new_line(25) and put(ansi esc sequence).  I would use the ansi esc
>sequence but, what if the computer I execute my program on doesnt have
>an ansi driver loaded?    Thanks in advance

If you're on a UNIX system, there are Ada bindings (for GNAT, I
believe) included in the latest ncurses library (tho I haven't tried
them personally).

Since you mentioned "ansi driver," however, I imagine you're using
DOS.  Under DOS, the best way (IMHO) to manipulate the screen is by
direct BIOS calls and/or by manipulating the video memory.  I don't
know how to do systems-level programming (interrupts, etc.) with Ada,
but it is possible.  As a side note, you should abstract all that away
with a clean interface.

A bunch of us should band together to create a good DOS screen
manipulation package.  Ada needs a larger body of common tools for the
common programmer.  Graphics and screen manipulation, as well as file
handling, are several things that come to mind.  If these packages
(not bindings, but bona fide Ada packages) already exist, it would be
very nice to know where we can find them.  :)

Good luck!

Re: Clear Screen

[Michael F Brenner]

  >  bunch of us should band together to create a good DOS screen
  > manipulation package.  Ada needs a larger body of common tools for the
  > common programmer.  Graphics and screen manipulation, as well as file
  > handling, are several things that come to mind.  If these packages
  > (not bindings, but bona fide Ada packages) already exist, it would be
  > very nice to know where we can find them.  :)

Ole! Yes, we need to get a large body of Free code available, bug-free,
and with fast performance. DOS system level code is needed.  

The following excerpts of my Free source code give an outline of the memory
locations needed to do machine dependent DOS text screen manipulation. This
should always be done directly to the hardware like this, because this 
always runs faster than any windowing system can light up characters. Some
Ada programmers are very much into quality, style, and machine independence.
But these attributes of a program are just methods of delivering Performance
to the user, and have no intrinsic value outside of this performance. In
drawing characters on the screen, speed is a very important component of performance. 

This method works on the raw hardware and under the DOS operating system. 
Windows NT 4.0 prevents access to these memory locations unless you are
using the game developers kit. 

  function key_bios return unsign.unsigned_8 is
    register: dosutils.registers_16;
    BIOS_keyboard_interrupt: constant := 16#16#;
    BIOS_keyboard_read:      constant := 16#1000#;
    use DOSutils;
    use unsign;
  begin
    register.ax := BIOS_keyboard_read;
    dosutils.interrupt_16 (BIOS_keyboard_interrupt, register);
    return unsign.unsigned_8 (register.ax mod 256);
    -- al is the ascii char (00 or e0); ah is the extended scan code
  end key_bios;

  function key_os return unsign.unsigned_8 is
    register: dosutils.registers_16;
    DOS_keyboard_interrupt:   constant := 16#21#;
    DOS_keyboard_read_noecho: constant := 16#0800#;
    use DOSutils;
    use unsign;
  begin
    register.ax := DOS_keyboard_read_noecho;
    dosutils.interrupt_16 (DOS_keyboard_interrupt, register);
    return unsign.unsigned_8 (register.ax mod 256);
  end key_os;

  function slitet return signals is
  begin
    return signals ((unsigned_8'(memory.get (lighter)) and 16#F0#) / 16);
  end slitet;

  procedure slitet (signal: signals) is
    surrounding_tissue: unsigned_8 := memory.get (lighter) and 15;
  begin
    memory.put (lighter, surrounding_tissue or (unsigned_8(signal) * 16));
    os.low_level_display(string'(1=>ascii.nul)); -- Forces DOS to read 417.
  end slitet;
 speakerSolenoid: constant := 16#61#;
 seed: rand.seeds;

 procedure nosound is
   maskSpeakerOff: constant unsigned_8 := 16#fc#;
 begin
   ioport.put (speakerSolenoid,
               ioport.get (speakerSolenoid) and maskSpeakerOff);
     --disk drive status is saved, and auto-interrupt sound is turned off
 end nosound;

procedure sound (frequency: frequencies) is
   timerInterrupt: constant unsigned_8:= 3;
   magicNumber: constant frequencies := 1193180; -- not a frequency
   timerPort: constant             := 16#42#;
   timerRate: frequencies;
   clipped_frequency: frequencies := frequency;
 begin
   if soundEffectsEnabled then
     if frequency < 19 then
       clipped_frequency := 19; -- prevent overflow
     end if;
     timerRate := magicNumber / clipped_frequency;
     ioport.put (timerPort, unsigned_8 (timerRate mod 256));
     ioport.put (timerPort, unsigned_8 (timerRate / 256));
     ioport.put (speakerSolenoid,
                 ioport.get (speakerSolenoid) or timerInterrupt);
     --speaker output is enabled
   end if;
 end sound;

with memory; -- pure
with unsign; -- pure
package body text_surface is
  use memory;

  procedure assert (condition: boolean) is
    text_surface_not_initialized: exception;
  begin
    if not condition then
      raise text_surface_not_initialized;
    end if;
  end assert;

  procedure clear (text_surface: text_surfaces) is
  begin
    assert (text_surface.initialized);
    blanks (text_surface, 0, 0,
            natural (text_surface.current_last_row + 1) *
            natural (text_surface.current_last_column + 1));
  end clear;

  procedure initialize (text_surface: in out text_surfaces) is
    t: text_surfaces renames text_surface;
  begin
    t.initialized := True;
    set_Foreground (t, white);
    set_background (t, blue);
    t.current_last_row := last_row (t);
    t.current_last_column := last_column (t);
  end initialize;

  procedure finalize (text_surface: in out text_surfaces) is
  begin
    assert (text_surface.initialized);
    text_surface.initialized := False;
  end finalize;

  function address (text_surface: text_surfaces;
                    column: columns;
                    row: rows) return addresses is

    text_address:        constant addresses := 16#b8000#;
    row_contribution:    constant addresses :=
      addresses (row) * addresses (text_surface.current_last_column+1);
    column_contribution: constant addresses := addresses (column);
  begin
    assert (text_surface.initialized);
    return text_address + 2 * (column_contribution + row_contribution);
  end address;

  procedure blanks (text_surface: text_surfaces;
                    column: columns;
                    row: rows;
                    count: natural) is
    a:    constant addresses := address (text_surface, column, row);
    use unsign;
    pair: constant unsigned_16 :=
      shift_left (unsigned_16 (text_surface.current_color), 8) +
      character'pos (' ');
  begin
    assert (text_surface.initialized);
    for i in 1..addresses(count) loop -- faster as buffer instead of loop?
      put (a - 2 + 2*i, pair);
    end loop;
  end blanks;
^  procedure colors_only (text_surface: text_surfaces;
                         column: columns;
                         row: rows;
                         count: natural) is
    a:    constant addresses := address (text_surface, column, row);
    byte: constant unsign.unsigned_8 :=
                   unsign.unsigned_8 (text_surface.current_color);
  begin
    assert (text_surface.initialized);
    for i in 1..addresses(count) loop
      put (a - 1 + 2*i, byte);
    end loop;
  end colors_only;

  function last_row (text_surface: text_surfaces)
                     return rows is
  begin
    assert (text_surface.initialized);
    return text_surface.current_last_row;
  end last_row;

  function last_column (text_surface: text_surfaces)
                        return columns is
  begin
    assert (text_surface.initialized);
    return text_surface.current_last_column;
  end last_column;

  function last_row return rows is
    byte: constant unsign.unsigned_8 := get (16#484#);
  begin
    return rows (byte);
  end last_row;

  function last_column return columns is
    byte: constant unsign.unsigned_8 := get (16#44a#);
  begin
    return columns (byte) - 1;
  end last_column;
  procedure message (text_surface: text_surfaces;
                     column: columns;
                     row: rows;
                     message: string) is
    a:    constant addresses := address (text_surface, column, row);
  begin
    assert (text_surface.initialized);
    for i in 1..message'length loop
      declare
        use unsign;
        pair: constant unsigned_16 :=
          shift_left (unsigned_16 (text_surface.current_color), 8) +
          character'pos (message (i));
      begin
        put (a - 2 + 2*addresses(i), pair);
      end;
    end loop;
  end message;
  procedure recompute_color (t: in out text_surfaces) is
    b_contribution: constant hues := colors'pos (t.current_background);
    f_contribution: constant hues := colors'pos (t.current_foreground);
    shift_left_4:   constant := 2**4;
    hue: constant hues := f_contribution + b_contribution * shift_left_4;
  begin
    assert (t.initialized);
    t.current_color := hue;
  end recompute_color;

  procedure set_foreground (text_surface: in out text_surfaces;
                            color: colors) is
  begin
    assert (text_surface.initialized);
    text_surface.current_foreground := color;
    recompute_color (text_surface);
  end set_foreground;
  procedure set_background (text_surface: in out text_surfaces;
                            color: colors) is
  begin
    assert (text_surface.initialized);
    text_surface.current_background := color;
    recompute_color (text_surface);
  end set_background;

end text_surface;
package communication_control

Clear Screen

[Karlene]

How can you clear the screen in your program??

Re: Clear Screen

[Robert Dewar]

In article <8gntbp$mei$1@news.cowan.edu.au>,
  "Karlene" <kejohnso@student.ecu.edu.au> wrote:
> How can you clear the screen in your program??

This is an operating system and compiler version related
question. You need to look this up in the documentation for
the particular compiler you are using. To get any help here
you need to say what machine you are using, what operating
system and version, and what compiler and version.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Clear Screen

[David C. Hoos, Sr.]

Karlene <kejohnso@student.ecu.edu.au> wrote in message
news:8gntbp$mei$1@news.cowan.edu.au...
> How can you clear the screen in your program??
>
This depends on your operating system.

Re: Clear Screen

[MARIE Eric]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

what's Clearscreen for win 98, please.
and for Unix  HP UX with VT 100 Emulation.


"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> a �crit dans le message
news: 9NMX4.1578$VO2.38467@newsread2.prod.itd.earthlink.net...
>
> Karlene <kejohnso@student.ecu.edu.au> wrote in message
> news:8gntbp$mei$1@news.cowan.edu.au...
> > How can you clear the screen in your program??
> >
> This depends on your operating system.
>
>
>
>

Re: Clear Screen

[Sune Falck]

In article <Nr3Y4.1974$GL4.5283952@nnrp5.proxad.net>, "MARIE Eric" <e.marie@worldonline.fr> wrote:
>what's Clearscreen for win 98, please.
>and for Unix  HP UX with VT 100 Emulation.
>
>
The simple and "portable" way to clear the screen is to
write enough New_Line:s to scroll the the visible text
out of the screen.

Example:

with Ada.Text_IO;
procedure Clear_Screen is
begin
   Ada.Text_IO.New_Line (25);
   Ada.Text_IO.Put_Line ("The screen was cleared");
end Clear_Screen;

This works for Windows 98 in a console window and
for all different terminal emulations in the unix world.

Sune Falck 
 

Re: Clear Screen

[Tarjei Tj�stheim Jensen]

Sune Falck wrote:
> The simple and "portable" way to clear the screen is to
> write enough New_Line:s to scroll the the visible text
> out of the screen.
> 
> Example:
> 
> with Ada.Text_IO;
> procedure Clear_Screen is
> begin
>    Ada.Text_IO.New_Line (25);
>    Ada.Text_IO.Put_Line ("The screen was cleared");
> end Clear_Screen;
> 
> This works for Windows 98 in a console window and
> for all different terminal emulations in the unix world.

It does not work for my terminal windows which are routinely both higher
and wider than 80x25.

The only simple reasonably portable way is to clear the screen with the
correct escape sequence and then position the cursor in the upper left
corner with another escape sequence.

A more complicated way would be to test for environment variables and
see whether they contain TERMCAP information. If that fails one could
look for termcap/terminfo. Newer unix telnetd/shell versions keep track
of the width and size of the window and store them in a couple of
environment variables.


Greetings,

Re: Clear Screen

[MARIE Eric]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

thank, you,
but the cursor is not in line1, col 1 location after 25 new_line.

and the set_col and set_line ... ?




"Sune Falck" <Sune.Falck@swipnet.se> a �crit dans le message news:
Pc5Y4.1746$b55.4361@nntpserver.swip.net...
> In article <Nr3Y4.1974$GL4.5283952@nnrp5.proxad.net>, "MARIE Eric"
<e.marie@worldonline.fr> wrote:
> >what's Clearscreen for win 98, please.
> >and for Unix  HP UX with VT 100 Emulation.
> >
> >
> The simple and "portable" way to clear the screen is to
> write enough New_Line:s to scroll the the visible text
> out of the screen.
>
> Example:
>
> with Ada.Text_IO;
> procedure Clear_Screen is
> begin
>    Ada.Text_IO.New_Line (25);
>    Ada.Text_IO.Put_Line ("The screen was cleared");
> end Clear_Screen;
>
> This works for Windows 98 in a console window and
> for all different terminal emulations in the unix world.
>
> Sune Falck
>

Re: Clear Screen

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]


Karlene <kejohnso@student.ecu.edu.au> a �crit dans le message :
8gntbp$mei$1@news.cowan.edu.au...
> How can you clear the screen in your program??
>
>

Under Windows (95/98/NT/2000) you could use NT_Console package.

See Jerry Web page: http://stad.dsl.nl/~jvandyk/

Pascal.

--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: p.obry@der.edf.fr         |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|         http://perso.wanadoo.fr/pascal.obry
--|
--|   "The best way to travel is by means of imagination"

Clear screen

[David Tumpa]

I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
the code to clear the screen with this compiler.

I know that this question is simple, but it is killing me.

Thanks,

Re: Clear screen

[Adrian Knoth]

David Tumpa <dtumpa@home.com> wrote:

> I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
> the code to clear the screen with this compiler.

Perhaps your screen understands some ESC-sequences... a general
solution would be:

  procedure ClearScreen is
  begin
    Text_IO.Put (Item => ASCII.ESC);
    Text_IO.Put (Item => "[2J");
  end ClearScreen;

Feel free to optimize it :)

Taken from:

--::::::::::
--screen.adb
--::::::::::
with Text_IO;
package body Screen is

  -- simple ANSI terminal emulator
  -- Michael Feldman, The George Washington University
  -- July, 1995

  -- These procedures will work correctly only if the actual
  -- terminal is ANSI compatible. ANSI.SYS on a DOS machine
  -- will suffice.



-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Wer im Glashaus sitzt sollte sein Klo im Keller haben.

Re: Clear screen

[John McCabe]

On Tue, 06 Nov 2001 20:19:16 GMT, "David Tumpa" <dtumpa@home.com>
wrote:

Do you mean to clear a console window? If so I would guess it is one
of the ANSI Escape Codes. Have a look here...

http://www.evergreen.edu/user/serv_res/research/bsi/people/dawn/program/ansi_esc.htm

>I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
>the code to clear the screen with this compiler.
>
>I know that this question is simple, but it is killing me.
>
>Thanks,
>
>
>

Re: Clear screen

[Jeffrey Carter]

John McCabe wrote:
> 
> Do you mean to clear a console window? If so I would guess it is one
> of the ANSI Escape Codes. Have a look here...

Except that those don't work on WinNT. For that you need Jerry Van
Dijk's NT_Console package available from

http://home.trouwweb.nl/Jerry/packages.html#CONSOLE

-- 
Jeffrey Carter

Re: Clear screen

[Darren New]

David Tumpa wrote:
> I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
> the code to clear the screen with this compiler.

for I in 1 .. 500 loop Put_Line end;

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: Clear screen

[Preben Randhol]

On Wed, 07 Nov 2001 16:52:46 GMT, Darren New wrote:
> David Tumpa wrote:
>> I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
>> the code to clear the screen with this compiler.
> 
> for I in 1 .. 500 loop Put_Line end;

Which is horribly slow in a MS-DOS windows under Windows.

I think you can reduce it to 50 anyway as we are talking about lines not pixels.

Preben
-- 
Please, stop bombing civilians in Afghanistan. One cannot write off
killing innocent children and other civilians as "collateral damage".
A civilian is a civilian whether he or she is American or from another
country in the world.           http://web.amnesty.org/11september.htm

Re: Clear screen

[tmoran]

> > I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
> > the code to clear the screen with this compiler.
>
> for I in 1 .. 500 loop Put_Line end;
  Ada.Text_IO.New_Page;

But perhaps this isn't a console screen, but is a window (it's running
under Windows, after all), in which case calling
  InvalidateRect(Window_Handle, 0, 1);
may be more appropriate.

Re: Clear screen

[Larry Kilgallen]

In article <3BE966CE.8D3628C1@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> David Tumpa wrote:
>> I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
>> the code to clear the screen with this compiler.
> 
> for I in 1 .. 500 loop Put_Line end;
                                  ^^^
                                end loop

Re: Clear screen

[Darren New]

Larry Kilgallen wrote:
> > for I in 1 .. 500 loop Put_Line end;
>                                   ^^^
>                                 end loop

Yes, and I missed the semicolon after Put_Line too. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: Clear screen

[Preben Randhol]

On Wed, 07 Nov 2001 21:31:31 GMT, Darren New wrote:
> Larry Kilgallen wrote:
>> > for I in 1 .. 500 loop Put_Line end;
>>                                   ^^^
>>                                 end loop
> 
> Yes, and I missed the semicolon after Put_Line too. :-)

Which shows that writing it in one line is not a good idea.

Preben
-- 
Please, stop bombing civilians in Afghanistan. One cannot write off
killing innocent children and other civilians as "collateral damage".
A civilian is a civilian whether he or she is American or from another
country in the world.           http://web.amnesty.org/11september.htm

Re: Clear screen

[Darren New]

Preben Randhol wrote:
> 
> On Wed, 07 Nov 2001 21:31:31 GMT, Darren New wrote:
> > Larry Kilgallen wrote:
> >> > for I in 1 .. 500 loop Put_Line end;
> >>                                   ^^^
> >>                                 end loop
> >
> > Yes, and I missed the semicolon after Put_Line too. :-)
> 
> Which shows that writing it in one line is not a good idea.

No, it just shows that I've only been writing Ada programs for a couple
weeks, and I keep switching between languages, and I should probably try
compiling even one-liners before I shoot them off.

On the other hand, if the OP can't figure out from the error message
that there's a semicolon missing, they shouldn't be programming at all.
;-)

Is the "end loop" really required? I thought "end" was OK anywhere
except at the end of a subprogram or package, yes?
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.

Re: Clear screen

[Pascal Obry]

Darren New <dnew@san.rr.com> writes:

> Is the "end loop" really required? I thought "end" was OK anywhere
> except at the end of a subprogram or package, yes?

Yes it is required. As "end case", "end record", "end if". The exception is
for "end <name>" where name could be a procedure or function name, 
block name...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Clear screen

[Jeffrey Carter]

Larry Kilgallen wrote:
> 
> In article <3BE966CE.8D3628C1@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> > David Tumpa wrote:
> >> I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
> >> the code to clear the screen with this compiler.
> >
> > for I in 1 .. 500 loop Put_Line end;
>                                   ^^^
>                                 end loop

For that matter Put_Line requires an argument and must be terminated by
a semicolon. New_Line would be better.

-- 
Jeffrey Carter

Re: Clear screen

[John English]

Darren New wrote:
> 
> David Tumpa wrote:
> > I am using the Aonix compiler on Windows ME and NT 4.0.  Can anyone give me
> > the code to clear the screen with this compiler.
> 
> for I in 1 .. 500 loop Put_Line end;

Try New_Line(500) as a swifter way to do the same.
But, overall I recommend Jerry van Dijk's NT_Console package.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Clear screen

[Nick Roberts]

"John English" <je@brighton.ac.uk> wrote in message
news:3BF13D82.C1F9081D@brighton.ac.uk...
> Try New_Line(500) as a swifter way to do the same.

Presumably

   New_Line(24);

would be swifter still? (Okay you might need 50).

--
Best wishes,
Nick Roberts

Re: Clear screen

[John English]

Nick Roberts wrote:
> 
> "John English" <je@brighton.ac.uk> wrote in message
> news:3BF13D82.C1F9081D@brighton.ac.uk...
> > Try New_Line(500) as a swifter way to do the same.
> 
> Presumably
> 
>    New_Line(24);
> 
> would be swifter still? (Okay you might need 50).

I think I meant to write 50, not 500, but my finger slipped... :-(

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Clear screen

[Daniel Krupke]

but this routine is not Clear Screen: the cursor is at bottom of the page,
but Clear Screen means that the cursor has to be at the first line!

is there any better way?

so long,
Daniel K.

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> schrieb im Newsbeitrag
news:9trsj1$4jgf9$1@ID-25716.news.dfncis.de...
> "John English" <je@brighton.ac.uk> wrote in message
> news:3BF13D82.C1F9081D@brighton.ac.uk...
> > Try New_Line(500) as a swifter way to do the same.
>
> Presumably
>
>    New_Line(24);
>
> would be swifter still? (Okay you might need 50).
>
> --
> Best wishes,
> Nick Roberts
>
>
>

Re: Clear screen

[Larry Kilgallen]

In article <9um95f$9cp80$1@ID-119234.news.dfncis.de>, "Daniel Krupke" <dkrupke@web.de> writes:
> but this routine is not Clear Screen: the cursor is at bottom of the page,
> but Clear Screen means that the cursor has to be at the first line!

By what definition does Clear Screen mean the cursor has to be
at the first line ?

Have you tried sending cursor command characters for whatever
terminal or emulator you are using ?

Re: Clear screen

[John English]

Daniel Krupke wrote:
> 
> but this routine is not Clear Screen: the cursor is at bottom of the page,
> but Clear Screen means that the cursor has to be at the first line!
> 
> is there any better way?

Sigh. You're back to Put(ASCII.ESC & "[2J") for an ANSI-compliant
display, or Jerry van Dijk's NT Console package if you're using NT,
or some other platform-dependent solution.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------