Description Knut Radloff 2001-10-11 14:19:53 EDT

The following will throw a StringIndexOutOfBounds exception.

	widget.setText("L1\r\nL2\r\nL3\r\nL4\r\n");
	widget.replaceTextRange(3, 0, "test");

The exception occurs in StyledText.handleTextChanging when constructing the 
new line text.  


NOTES:

KR (5/29/01 6:14:57 PM)
	Splitting line breaks (i.e., creating two lines by inserting text between the two bytes of a line break) 
	is not supported.	
	The following is valid with the same result:
		widget.setText("L1\r\nL2\r\nL3\r\nL4\r\n");
		widget.replaceTextRange(3, 1, "test\n");

LK (6/20/01 11:39:32 AM)
	Need to handle this in DefaultContent.  Common problem.

McQ (26/06/2001 2:13:41 PM) -
	Also, need to ensure that StyledText is less sensitive in general to
	problems with the content providers.

LK (7/9/2001 12:48:57 PM)
	Don't agree with the assessment above.  If we try to handle all problems that the user can cause when
	supplying their own content implementation, we'll introduce A LOT of overhead and complexity.
	I think it is correct to expect the user to take some responsiblity if they are providing their own
	content implementation.  Other SWT widgets certainly do not follow the approach above (e.g., 
	if you supply bogus info walkbacks/exceptions occur).

LK (7/9/2001 12:52:28 PM)
	DefaultContent is updated now to handle these special cases.  IllegalArgumentException will be
	thrown if the user attempts to do a bogus replace operation.  Other content implementors should
	do this or handle bogus replace operations correctly (i.e., answer the right number of new lines and
	replaced lines in the TextChanging callback data).

KR (7/9/01 1:48:12 PM)
	We could assume worst case behavior when getting/using data from StyledTextContent and 
	LineStyleListeners and catch StringIndexOutOfBoundsExceptions and 
	ArrayIndexOutOfBoundsExceptions. That's free and prevents us from failing badly (instead we
	will fail by rendering incorrectly or not rendering anything for example).

LK (7/9/01 5:07:17 PM)
	So if the TextChangingEvent has bogus information, basically any place that StyledText
	calls StyledTextContent for information needs to be considered a possible failure condition.  So
	all the places where methods like getLine(int), getLineAtOffset(int), getTextRange(int, int) are called
	would have to be wrapped with an exception handler.  I don't see any other way since we 
	can't make any assumptions about their implementation (e.g., what delimiters they are supporting,
	how they are storing their text).

	I really feel that we should not go down this path.  I also feel it is incorrect to "hide" the problems from 
	the user.  The place that these errors should be detected and handled should be in the StyledTextContent
	implementation.  Basically they are giving US bad information about THEIR data.  How can WE know that?