[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsEx
From:       Robert Lichtenberger <rlichten () openjdk ! java ! net>
Date:       2020-05-28 6:53:08
Message-ID: 6WhyH_3NIHMKxVw-xsTv6jAsSb2njDPkaaNVz64y60E=.352fb913-33e4-40ee-a28b-9da54e7095c8 () github ! com
[Download RAW message or body]

On Wed, 27 May 2020 12:11:48 GMT, Robert Lichtenberger <rlichten@openjdk.org> wrote:

> > you are hacking around ;)
> > 
> > doSelect _must not_ be called somewhere "in-between" changing the text: the api \
> > doc clearly states that the caret/anchor coordinates are the _new_ coordinates, \
> > that is after all changes have been applied. When re-calculating them on-the-fly \
> > might have unexpected side-effects, f.i. if a TextFormatter had something special \
> > in mind (no failing test handy though).
> 
> Most of the time, value in javafx.scene.control.TextInputControl.replaceText(int, \
> int, String, int, int) will already be filtered (e.g. linebreaks in TextField) In \
> that case, adjustmentAmount will be zero and one could just do the selection before \
> actually inserting the text. But a case can be constructed with a TextFormatter \
> that will produce characters that will be filtered by the TextField itself:
> 
> @Test public void replaceSelectionWithFilteredCharacters() {
> txtField.setText("x xxxyyy");
> txtField.selectRange(2, 5);
> txtField.setTextFormatter(new TextFormatter<>(this::noDigits));
> txtField.replaceSelection("a1234a");
> assertEquals("x aayyy", txtField.getText());
> assertEquals(4, txtField.getSelection().getStart());
> assertEquals(4, txtField.getSelection().getStart());
> }
> 
> private Change noDigits(Change change) {
> Change filtered = change.clone();
> filtered.setText(change.getText().replaceAll("[0-9]","\n"));
> return filtered;
> }

The last commit on this branch seems like the "best" way to fix this problem. It \
prevents in-between changes in selectedText and does not introduce (to the best of my \
knowledge) any new corner cases. It eliminiates the "root cause" of the problem by \
postponing selectedText update to the end of whole replace-operation. So, this is RFR \
now (I hope).

-------------

PR: https://git.openjdk.java.net/jfx/pull/138


[prev in list] [next in list] [prev in thread] [next in thread]