disable putchar line-wrapping?

[John den Haan]

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

 

[Guest]

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.

 

[John den Haan]

Harald van Dijk schreef:

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

 

[Ian Collins]

Harald van Dijk schreef:


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.

 

[Walter Roberson]

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.

 

[Keith Thompson]

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.

 

[CBFalconer]

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

 

[Gordon Burditt]

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.