> That is one of those questions that is best answered by trying it yourself.
> Write two lines into a TextArea and then read it back: see what you get. If
> you can, try it again in a different Operating System and see if you get the
> same line separator.
No, it's really not. Testing can never establish whether some behavior
is merely coincidental or guaranteed.
I can't find a good answer easily. The implication from evaluations of
a few bug reports is that AWT components insert a single '\n' when the
user hits enter, regardless of platform, but if you intentionally store
a \r\n into the text field, then Sun's intention is that it should be
displayed as you expect; but really don't do it anyway. Anyone see a
good answer anywhere?

Signature
Chris Smith
Tony Dahlman - 23 Nov 2006 06:34 GMT
>> I can't find a good answer easily. The implication from evaluations of
a few bug reports is that AWT components insert a single '\n' when
the
user hits enter, regardless of platform, but if you intentionally
store
a \r\n into the text field, then Sun's intention is that it should be
displayed as you expect; but really don't do it anyway. Anyone see a
good answer anywhere?
<<
The answer is that the crlf entered in an AWT Text Field is "guaranteed to
be" platform dependent, isn't it? Of course there were bugs in years past
since whole sections of the Java libraries were imported from C++ Unix
code.
But that was gone by the time Java 1.3 came out, wasn't it?
Anyway, I don't think it hurts to include a call like:
String newLine = System.getProperty( "line.separator" );
..in your code just to be sure that your code will run everywhere (as
opposed to being debugged everywhere) ;-).
TonyD
Chris Uppal - 23 Nov 2006 14:05 GMT
> I can't find a good answer easily. The implication from evaluations of
> a few bug reports is that AWT components insert a single '\n' when the
> user hits enter, regardless of platform, but if you intentionally store
> a \r\n into the text field, then Sun's intention is that it should be
> displayed as you expect; but really don't do it anyway. Anyone see a
> good answer anywhere?
The actual behaviour seems to be a little more complex than that. I assume
(without evidence) that it's by design.
I haven't tried all possibilities, but it appears that if you start with text
containing only \n as its separator (running on Windows), then
java.awt.TextArea appears to preserve that, and if you edit the text manually,
then it adds just more \n-s to the text. So far, so good. But if you start
with text that contains at least one \r\n sequence (such as text loaded from a
Windows text file), then it switches mode, and maps all \n-s into \n\r pairs,
including whatever you enter manually.
That's using 1.5.0_6 on WinXP.
-- chris
====== little test proggy ========
import java.awt.*;
import java.awt.event.*;
public class Test
{
// play with this to experiment
static String string = "0123456789\r\n0123456789\n0123456789\n";
public static void
main(String[] args)
{
Frame frame = new Frame("Test");
TextArea text = new TextArea(string);
frame.add(text);
text.addMouseListener(new Tracker());
frame.pack();
frame.setVisible(true);
System.out.println("Size: "
+ string.length() // 34
+ " "
+ text.getText().length()); // 36
}
}
class Tracker
extends MouseAdapter
{
public void
mouseClicked(MouseEvent e)
{
track((TextArea)(e.getComponent()));
}
public void
mouseReleased(MouseEvent e)
{
track((TextArea)(e.getComponent()));
}
private void
track(TextArea text)
{
System.out.println("Selection: ["
+ text.getSelectionStart()
+ ", "
+ text.getSelectionEnd()
+ ") = "
+ text.getSelectedText().length()
+ " out of "
+ text.getText().length()
+ " chars");
}
}
======================