«

Hello!

When I use putchar to fill up an entire screen (of 80x25) with text, it
seems to leave an empty line at the end, thus forcing me to scroll
upwards in to see the first line. This forces me to repositioning the
cursor to the first line, which costs computer power. I know the loss is
negligible, but it's more a matter of principle: how to prevent this
line-wrapping behaviour?

--

Cheers,

John den Haan
joDhn[dot]haEan[at]chLello[dot]nl

Remove capital 'DEL' from above addy to obtain e-mail address

John den Haan wrote:
> Hello!
>
> When I use putchar to fill up an entire screen (of 80x25) with text, it
> seems to leave an empty line at the end, thus forcing me to scroll
> upwards in to see the first line. This forces me to repositioning the
> cursor to the first line, which costs computer power. I know the loss is
> negligible, but it's more a matter of principle: how to prevent this
> line-wrapping behaviour?

In standard C, it's simply not possible, sorry. A newsgroup for your
specific system may be able to give a system-specific answer.

Harald van Dijk schreef:
> John den Haan wrote:
>> Hello!
>>
>> When I use putchar to fill up an entire screen (of 80x25) with text, it
>> seems to leave an empty line at the end, thus forcing me to scroll
>> upwards in to see the first line. This forces me to repositioning the
>> cursor to the first line, which costs computer power. I know the loss is
>> negligible, but it's more a matter of principle: how to prevent this
>> line-wrapping behaviour?
>
> In standard C, it's simply not possible, sorry. A newsgroup for your
> specific system may be able to give a system-specific answer.
>

Does C offer alternatives to putchar that do not wrap?

--

Cheers,

John den Haan
joDhn[dot]haEan[at]chLello[dot]nl

Remove capital 'DEL' from above addy to obtain e-mail address

John den Haan wrote:
> Harald van Dijk schreef:
>
>> John den Haan wrote:
>>
>>> Hello!
>>>
>>> When I use putchar to fill up an entire screen (of 80x25) with text, it
>>> seems to leave an empty line at the end, thus forcing me to scroll
>>> upwards in to see the first line. This forces me to repositioning the
>>> cursor to the first line, which costs computer power. I know the loss is
>>> negligible, but it's more a matter of principle: how to prevent this
>>> line-wrapping behaviour?
>>
>>
>> In standard C, it's simply not possible, sorry. A newsgroup for your
>> specific system may be able to give a system-specific answer.
>>
>
> Does C offer alternatives to putchar that do not wrap?
>
Standard C does not provide a means to determine the properties of the
standard output. You have to use an platform specific library.

--
Ian Collins.

In article <d7a35$45d8c058$d4bb52d9$>,
John den Haan <> wrote:
>Does C offer alternatives to putchar that do not wrap?

It isn't putchar() that is doing the wrapping: it is the terminal
emulation layer that the text is being displayed on to. There might
or might not be a way to control the wrapping behaviour of that
emulation layer, but if there is, then it is specific to that emulation
layer and not part of C. You'll probably find there are different
terminal emulation behaviours for different products even for the same OS,
so this really isn't something we can answer here.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

John den Haan <> writes:
> When I use putchar to fill up an entire screen (of 80x25) with text,
> it seems to leave an empty line at the end, thus forcing me to scroll
> upwards in to see the first line. This forces me to repositioning the
> cursor to the first line, which costs computer power. I know the loss
> is negligible, but it's more a matter of principle: how to prevent
> this line-wrapping behaviour?

You didn't tell us *how* you use putchar to fill up the screen.

Do you write a newline character at the end of each of the 25 lines?
If so, on a typical display, the last newline will naturally cause the
disply to scroll up, leaving the cursor at the beginning of a blank
line.

If you print characters without a terminating newline, you should call
fflush(stdout) to ensure that they're displayed. (But some displays
may not be able to display a character in the lower right corner.)

Details of how displays work are target-specific, but we'll be glad to
help with any C issues.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson wrote:
> John den Haan <> writes:
>
>> When I use putchar to fill up an entire screen (of 80x25) with text,
>> it seems to leave an empty line at the end, thus forcing me to scroll
>> upwards in to see the first line. This forces me to repositioning the
>> cursor to the first line, which costs computer power. I know the loss
>> is negligible, but it's more a matter of principle: how to prevent
>> this line-wrapping behaviour?
>
> You didn't tell us *how* you use putchar to fill up the screen.
>
> Do you write a newline character at the end of each of the 25 lines?
> If so, on a typical display, the last newline will naturally cause the
> disply to scroll up, leaving the cursor at the beginning of a blank
> line.
>
> If you print characters without a terminating newline, you should call
> fflush(stdout) to ensure that they're displayed. (But some displays
> may not be able to display a character in the lower right corner.)
>
> Details of how displays work are target-specific, but we'll be glad to
> help with any C issues.

Whew. At last a sane answer to the query. But remember that
fflush only flushes the C system buffers - there may be (on poor
implementations) further op-system buffers to flush.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

>When I use putchar to fill up an entire screen (of 80x25) with text, it
>seems to leave an empty line at the end, thus forcing me to scroll
>upwards in to see the first line. This forces me to repositioning the
>cursor to the first line, which costs computer power.

Your posting probably used millions of times more than the picowatt
required to do that.

>I know the loss is
>negligible, but it's more a matter of principle: how to prevent this
>line-wrapping behaviour?

C doesn't guarantee that you have a screen, or that it will scroll
(ASR-33 Teletype anyone?).

For some terminals and/or terminal emulations, writing the character
at the bottom right of the screen scrolls the screen, and there's
not anything you can do about it. Sometimes there's a mode you can
turn on or off which makes it either scroll or wrap to the upper
left corner.

In the implementation of some versions of curses, and for some terminals,
you can set the bottom-right character using the following ugly hack:
(1) move the cursor to one left of the bottom-right character
(Direct cursor positioning if you've got it)
(2) write the character you want at the bottom-right there
(yes, this is one space off)
(3) move the cursor to one left of the bottom-right character
(same place as (1); often a cursor-left sequence will work)
(4) send a sequence to enable insert-character mode
(5) write the character you want to the left of the bottom-right there
This moves the character that was there one to the right.
(6) send a sequence to disable insert-character mode

Note that in order to change the bottom-right character, you have
to know what you want in the character to the left of it. No, you
can't depend on reading the screen, especially if the user is busy
entering data on the keyboard. Since curses keeps an image of how
it wants the whole screen to look anyway, this is not a problem.

Curses can use this sort of hack when necessary without the user
of curses having to deal with it.