New line in a JTextArea (student learning here)

Thread view:

Enable EMail Alerts

Start New Thread

Sandy - 28 Jan 2007 19:47 GMT

How does one append to a JTextArea in such a way to tell it that you
want this on a new line?

Thanks.

Reply to this Message

Knute Johnson - 28 Jan 2007 19:55 GMT

> How does one append to a JTextArea in such a way to tell it that you
> want this on a new line?
>
> Thanks.

JTextArea ta = new JTextArea();

ta.append("I want a new line at the end\n");

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Sandy - 28 Jan 2007 19:57 GMT

On Jan 28, 2:55 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:

> > How does one append to a JTextArea in such a way to tell it that you
> > want this on a new line?
[quoted text clipped - 7 lines]
> Knute Johnson
> email s/nospam/knute/

Thanks. Makes perfect sense, just like a console app with C or C++.
(Don't know why I didn't think of that! DOH!)

Reply to this Message

Farcus Pottysqirt - 29 Jan 2007 00:12 GMT

> On Jan 28, 2:55 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
> wrote:
[quoted text clipped - 13 lines]
> Thanks. Makes perfect sense, just like a console app with C or C++.
> (Don't know why I didn't think of that! DOH!)

Just don't forget the "\n" *newline character* at the end of every line
or else you'll end up with JTA-diahrea. I made this mistake myself once
and had a devil of a time trying to figure it out.

Hey.... does it work different on Windows than on Unix? Is the new-line
character represented differently on a different platform?

Reply to this Message

Andrew Thompson - 29 Jan 2007 06:27 GMT

On Jan 29, 11:12 am, Farcus Pottysqirt <where_is_my_...@movies.net>
wrote:
...

> ..Is the new-line
> character represented differently on a different platform?

Sure is. Best to initilaise the line feed character as..
System.getProperty( "line.separator" );

Andrew T.

Reply to this Message

Farcus Pottysquirt - 29 Jan 2007 15:22 GMT

> Sure is. Best to initilaise the line feed character as..
> System.getProperty( "line.separator" );
>
> Andrew T.

Interesting...I would never have guessed that.

Reply to this Message

Knute Johnson - 30 Jan 2007 01:35 GMT

> On Jan 29, 11:12 am, Farcus Pottysqirt <where_is_my_...@movies.net>
> wrote:
[quoted text clipped - 6 lines]
>
> Andrew T.

Andrew:

Do you know an OS that uses a different line feed that runs Java?

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Andrew Thompson - 30 Jan 2007 03:00 GMT

On Jan 30, 12:35 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:

> > On Jan 29, 11:12 am, Farcus Pottysqirt <where_is_my_...@movies.net>
> > wrote:
[quoted text clipped - 4 lines]
> > Sure is. Best to initilaise the line feed character as..
> > System.getProperty( "line.separator" );

...

> Do you know an OS that uses a different line feed that runs Java?

AFAIU, JRE's on windows did historically return \n\r,
whereas *nix variatns use only \n.

OTOH, using System.getProperty("line.separator"),
is 'forward compatible' in the sense that if any new
OS architectures were to become support, or either
Win/*nix to suddenly change the line separator
(my bet would be Windows), the code would adapt.

Andrew T.

Reply to this Message

Knute Johnson - 30 Jan 2007 03:58 GMT

> On Jan 30, 12:35 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
> wrote:
[quoted text clipped - 18 lines]
>
> Andrew T.

\n is a bad habit left over from my C days. I should probably watch
that in the future :-).

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Gordon Beaton - 30 Jan 2007 07:05 GMT

> AFAIU, JRE's on windows did historically return \n\r,
> whereas *nix variatns use only \n.

If I'm not mistaken, the Windows line end is \r\n (CRLF).

Also, MacOS has traditionally used \r (CR), although that changed to
\n (LF) with MacOS X (when it became a Unix variant).

/gordon

Signature

[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Reply to this Message

Andrew Thompson - 30 Jan 2007 07:26 GMT

> > AFAIU, JRE's on windows did historically return \n\r,
> > whereas *nix variatns use only \n.
>
> If I'm not mistaken, the Windows line end is \r\n (CRLF).

Thanks for clarifying.

> Also, MacOS has traditionally used \r (CR), although that changed to
> \n (LF) with MacOS X (when it became a Unix variant).

I completely forgot MacOS!

Andrew T.

Reply to this Message

Wojtek Bok - 30 Jan 2007 14:39 GMT

> OTOH, using System.getProperty("line.separator"),
> is 'forward compatible' in the sense that if any new
> OS architectures were to become support, or either
> Win/*nix to suddenly change the line separator
> (my bet would be Windows), the code would adapt.

Actually *nix should change. The action of moving the cursor to the beginning of a new line is in fact two operations:
- move the cursor down one line
- move the cursor to the beginning of the line

So the original DOS specification of CRLF is correct, whereas the professor at Berkley probably wanted to save a few bytes (at a time when storage was
expensive).

And this separation can be used by command line apps when displaying status:

for (some loop)
- do work
- print status to the console and append a carriage return (note NO line feed)

So the status is displayed on a single line and is updated only on that line.

Reply to this Message

RedGrittyBrick - 30 Jan 2007 20:54 GMT

>> OTOH, using System.getProperty("line.separator"),
>> is 'forward compatible' in the sense that if any new
[quoted text clipped - 4 lines]
> Actually *nix should change. The action of moving the cursor to the
> beginning of a new line is in fact two operations:

Two? How many buttons on your keyboard do you normally press to
accomplish this?

> - move the cursor down one line
> - move the cursor to the beginning of the line

Only for electromechanical teletypewriter machines that supported
overprinting and underlining that way. (and their successors that try to
be backwards compatible with carriage-control from the days when a
carriage was a large lump of metal driven by separate motors for
rotation/feed and for horizontal positioning).

> So the original DOS specification of CRLF is correct,

Carriage control CR LF long predates DOS so I'm not sure why you picked
that as an example. The Unix LF convention was established before DOS
existed.

The DOS specification for line separation/termination wasn't original -
in the sense of being novel, and it wasn't original - in the sense of
being first.

CR LF is only "correct" in the sense of being "traditional".

The ASCII standards didn't define a character or sequence for "line
separator" or "line terminator" in stored files.

Just my $0.02 worth.

Reply to this Message

Wojtek Bok - 30 Jan 2007 21:26 GMT

>>> OTOH, using System.getProperty("line.separator"),
>>> is 'forward compatible' in the sense that if any new
[quoted text clipped - 7 lines]
> Two? How many buttons on your keyboard do you normally press to
> accomplish this?

I do not have a CRLF button on my keyboard any more than I have a CR or an LF button. I do have an Enter button though. And the pretty graphic shows:
|
<----|

Which looks like two operations to me.

Oh, and the print screen button scrapes the screen, copies the result into a buffer, then prints the buffer. Pretty complex for one little button.

:-)

>> - move the cursor down one line
>> - move the cursor to the beginning of the line
[quoted text clipped - 4 lines]
> carriage was a large lump of metal driven by separate motors for
> rotation/feed and for horizontal positioning).

Yes, but it seemed to be a natural thing, as you do have two things happen.

>> So the original DOS specification of CRLF is correct,
>
> Carriage control CR LF long predates DOS so I'm not sure why you picked
> that as an example. The Unix LF convention was established before DOS
> existed.

Well, I started with DOS 1.0, so that comes naturally for me.

> The DOS specification for line separation/termination wasn't original -
> in the sense of being novel, and it wasn't original - in the sense of
[quoted text clipped - 4 lines]
> The ASCII standards didn't define a character or sequence for "line
> separator" or "line terminator" in stored files.

True, though for a text file dumped to a screen you do want new lines to start at the beginning of screen, one line down. This is two operations.

Which is why ASCII does have two specifications CR and LF.

Now as for separating information within a file (such as lines), you could use anything, as long as the file reader interprets it correctly.

Reply to this Message

RedGrittyBrick - 30 Jan 2007 23:58 GMT

>>> The action of moving the cursor to the
>>> beginning of a new line is in fact two operations:
[quoted text clipped - 3 lines]
>
> I do not have a CRLF button on my keyboard

You have a button that, in a single keypress operation, moves the cursor
to the start of the next line though.

> any more than I have a CR or an LF button.

I do, when I press Enter my terminal emulator sends CR (Not CR LF).

If I happen to be leaning on my Ctrl key then my J keys acts as an LF
key and I have a dedicated down-arrow key whose effects are often hard
to distinguish from LF.

> I do have an Enter button though. And the pretty graphic
> shows:
> |
> <----|
>
> Which looks like two operations to me.

Nah, then the pretty graphic would be

|
v, <--

Two operations should be two arrows shouldn't it?

>>> - move the cursor down one line
>>> - move the cursor to the beginning of the line
[quoted text clipped - 6 lines]
>
> Yes, but it seemed to be a natural thing, as you do have two things happen.

Not in a text file!

>> The ASCII standards didn't define a character or sequence for "line
>> separator" or "line terminator" in stored files.
>
> True, though for a text file dumped to a screen you do want new lines to
> start at the beginning of screen, one line down. This is two operations.

Is "move to start of next line" intrinsically two operations? More so
than "move to column 1 row 11"? I wouldn't be surprised if the latter is
what many curses applications end up sending to the terminal when the
user presses the Enter key.

If I have my text editor in autoindent mode and press Enter the cursor
rarely ends up in column 1 so a gotoXY is possibly selected by curses in
preference to CR LF Cursor-right Cursor-right ...

> Which is why ASCII does have two specifications CR and LF.

But screens don't have *carriages* so they don't need carriage-return.
They don't have paper to *feed* through a print position a line at a
time. Files especially don't have carriages or paper feeders so the need
for CR and LF together as line separators seems tenuous at best.

> Now as for separating information within a file (such as lines), you
> could use anything, as long as the file reader interprets it correctly.

Which is why LF is no less correct than CR or CR LF.

Never mind, I must be in an argumentative mood today :-)

Reply to this Message

John W. Kennedy - 31 Jan 2007 02:10 GMT

> Is "move to start of next line" intrinsically two operations?

A-priori design considerations aside, it factually /was/ two operations
on the historic teleprinters for which ASCII was first designed. (IBM
Selectric teleprinters, such as the 1052 and the 2741, had a combined
operation, and EBCDIC has a distinct "New-line" control character, in
addition to "Line-feed" and "Carriage-return".)

The reason that historic teleprinters combined the operations is very
likely the requirement for all operations to take place in one character
time. They had very narrow margins, and could do a carriage return in
the time it took to print one character; I suspect that adding the line
feed while retaining the speed would have significantly increased costs.
(IBM Selectric teleprinters could /not/ execute either a Carriage-return
or a New-line in one character time, both because they had wider
carriages and because they printed at nearly twice the character rate;
it was necessary to insert a number of Idle [do-nothing] control
characters to prevent the printer from trying to strike characters while
flying back. Same for tabs.)

> More so
> than "move to column 1 row 11"? I wouldn't be surprised if the latter is
> what many curses applications end up sending to the terminal when the
> user presses the Enter key.

ASCII is much older than curses. Indeed, when ASCII was being developed,
CRT terminals were hideously expensive and vector-based (like the old
"Asteroids" arcade game), and required a whole mainframe to drive them.
They were almost entirely limited to CAD, Air Traffic Control, and
similar applications.

Signature

John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

Reply to this Message

Farcus Pottysquirt - 30 Jan 2007 21:53 GMT

> Just my $0.02 worth.

I think that CRLF may have it's roots in the old manual typewriter days.
I took a typing course in grade 10 and we used manual typewriters.
The thing you hit on the right hand side of the machine to send the
"cursor" back to the start of the next line basically shot the "cursor"
back to the beginning of the current line and then you pushed a lever
and the paper moved up over the roller. Hence... Carriage Return...
Line Feed

Reply to this Message

New line in a JTextArea (student learning here)

Free Magazines