There is a bug in java.awt.TextArea & its superclass
java.awt.TextComponent on the Windows NT platform for the method
getText(). This method returns a '\n' delimitered string, while the
string indexing methods; getSelectionStart(), getSelectionEnd() and
getCaretPosition() appear to refer to a '\r\n' delimitered string.

This indexing difference causes numerous problems and can result in a
string out of bounds exception being thrown.


======================================

TextArea.getText() seems to return text that
is dilimited by the newline (\n) character when
there are multiple lines of text. If you try
to write this string to disk on a PC, it does
not look right because you really need \r\n at the
end of each line. It would be nice if getText()
would somehow allow the option of using \r\n where
appropriate (to be portable).

An alternative would be to allow getText(i) where
i is the row of text. Then the line could be
post-processed as appropriate.

Also, from the TextComponent and TextArea documentation,
it is unclear what delimiter is used for
multi-line output. It would be nice to know!

======================================================

1) Create a window with a text area
    Add menus or buttons to enable text copying,
       text cutting, and the selectAll() method
    Place a few lines of text within the text area
       and use '\n' to place text on specific
       lines.
    If you select any word on any line, and then
       perform a cut() (ie perform a getSelectedText()
       followed by a replaceRange()) the actual text
       that is cut (and stored into a global variable)
       will be offset 1 character forward for every
       '\n' previous to the beginning of the selected
       text.
I have a class project wherein this problem is made evident
I can send you a copy of the program (it isn't the best code)
and you can examine and modify the section of code that
contains the bug. I merely need an address to send it to.