FWD » Core Development » User Interface

Testcase:

DEFINE VARIABLE e1 AS CHARACTER
    VIEW-AS EDITOR size 10 by 10.
DEFINE FRAME f-main e1.
DO WITH FRAME f-main:
    e1:SCREEN-VALUE = "Something".
    e1:REPLACE("thing", "one", 1). // 1 corresponds to "FIND-NEXT-OCCURRENCE" type of search
    MESSAGE e1:SCREEN-VALUE. // "Someone" 
end.

The error:

java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 1
    at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
    at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
    at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
    at java.base/java.util.Objects.checkIndex(Objects.java:361)
    at java.base/java.util.ArrayList.get(ArrayList.java:427)
    at com.goldencode.p2j.ui.client.Editor.getLine(Editor.java:2151)
    at com.goldencode.p2j.ui.client.Editor.getCursorOffset(Editor.java:1413)
    at com.goldencode.p2j.ui.client.Editor.setCursorLine(Editor.java:1270)
    at com.goldencode.p2j.ui.client.gui.EditorGuiImpl.setCursorLine(EditorGuiImpl.java:2605)
    at com.goldencode.p2j.ui.client.Editor.replaceString(Editor.java:1792)
    at com.goldencode.p2j.ui.chui.ThinClient.replaceEditorString(ThinClient.java:6327)

As far as I know, this wasn't seen in any customer application. I stumbled upon it like ~10 months ago while working on tests for #8701, and noticed that it wasn't solved in the meantime.

The method triggering the error is Editor.setCursorLine() which accepts 1-based input values and converts them to 0-based explicitly.

if (line > parsedText.size())
{
   return false;
}

// convert it to 0-based
line -= 1;

While processing 'replace', we can only pass to this function what Editor.inSameLime() returns, which is 0-based, so the problem is that we are converting the value to 0-based, assuming it's 1-based.

• Hotel GUI + 2 customer app smoke-tests
• ChUI regression tests
• Commited rev. 1816 on testcases project which adds a test that passes with 10695a and fails with trunk
• Ran unit tests where possible

If this is enough, we should merge 10695a.