Add feature to InlineCssTextArea to dynamically change highlight color

Desired Feature

It’s currently possible to change dynamically/programmatically the text coloring with the InlineCssTextArea using for example:

setStyle(startRange, endRange, "-fx-fill:red");

Using “-fx-highlight-fill” does not seem to work and I have seen this property discussed elsewhere. It would be great to be able to also change the coloring of the (mouse) selection highlight on the fly via code, without a dependency on css stylesheets. Ideally you would be able to specify this per range (as you can for the the text fill color in the example above), however just being able to change the single color (from the default DODGERBLUE in the SelectionPath property) for all mouse selections on the fly would also be very useful. I can see that that Selection and CaretSelectionBind provide a:

    void configureSelectionPath(SelectionPath path);

method, but it does not seem possible to hook into this (and perhaps that would be the wrong approach anyway). It may already be possible to achieve this dynamically. If so, any directions would be much appreciated.

[Yossi-77]

Thanks again for the suggestion. I’ve tried that, but no luck. I’ve also tried putting the addSelection in a runLater (still no luck).

I have got something that does work though… It’s pretty desperate:

public class TestTextArea extends InlineCssTextArea {

	public TestTextArea() {

		final Selection underlyingSelection = getCaretSelectionBind().getUnderlyingSelection();

		Selection overlaySelection = new SelectionImpl("overlay", this, path -> ((Path) path).setFill(Color.GREEN)) {

			@Override
			public int hashCode() {

				return underlyingSelection.hashCode();
			}


			@Override
			public boolean equals(Object o) {

				return underlyingSelection.equals(o);
			}

		};

		selectionProperty().addListener((obs, oldVal, newVal) -> {

			removeSelection(overlaySelection);
			overlaySelection.selectRange(underlyingSelection.getStartParagraphIndex(), underlyingSelection.getStartColumnPosition(), underlyingSelection.getEndParagraphIndex(), underlyingSelection.getEndColumnPosition());
			addSelection(overlaySelection);
		});
	}
}

I think I could see in the code that the Selections end up in a set. There is a check in the code that should prevent the main underlying selection being removed, but given it’s going into a set, that check can be circumvented by hacking the equals method of any new Selection. My theory was that the underlying Selection was being rendered over the overlay Selection (I don’t know if that is actually true) and getting rid of the underlying Selection might leave the desired behavior.

If this gives you any clue as to how to put in place a cleaner solution it would be great to know. For now, I guess I will keep this in place, given it appears to function robustly, even if pretty terrible code.

[Yossi-77]

Solution found - link a custom Selection’s range to the underlying selection attached to the CaretSelectionBind and make the underlying selection transparent to prevent it rendering over the custom selection.