Caret visible on non-editable code area

[ghost]

Hi,
is it possible to make the caret visible when the code area is not enabled?

I am working on a terminal window and a visible (even blinking) caret would be great, but direct input must be disabled.

P.S. I am new to github so sorry if I am doing something wrong by posting this here...

[TomasMikula]

Hi Darko,

posting here is OK.

Caret visibility is hard-coded like this:

caretVisible = caretPulse
        .and(area.focusedProperty())
        .and(area.editableProperty())
        .and(area.disabledProperty().not());

That is, caret is visible, when

• the periodic pulse alternating between true and false is true
• and the area has focus
• and the area is editable
• and the area is not disabled.

As a consequence, an area that is not editable cannot have a visible caret.

[ghost]

Thanks for the swift reply Tomas. Any suggestions on how to imitate the caret? I tried adding a trailing whitespace and toggling its style with:

 List<String> styles = new ArrayList<String>();
                    syles.add("-fx-background-color: red;")
                    cArea.setStyle(0, 2, styles);

But it does not work.
I read that background color is not supported for ranges on text elements so I tried with font-size but the same thing happens.
I can see with GetStyleRangeAtPosition that the css is added but it is just not visible. The same thing happens with SetStyleClass. Setting css for the whole cArea (no range) works fine.
I have now gone the way of adding and removing a trailing '|' but would really appreciate any suggestions on how to imitate the caret.

Thank you

[TomasMikula]

I suppose your cArea is a StyleClassedTextArea, correct? The code above would not work for two reasons:

1. In your case, -fx-background-color: red; is interpreted as a style class.
2. Text node does not support background color anyway.

Unfortunately, there is no reliable way to imitate the caret. You could create your own fork of RichTextFX and change the definition of caret visibility in the source code.

If you stick to your workaround, you may want to consider using Unicode characters ░ ('\u2591'), ▒ ('\u2592') or ▓ ('\u2593') instead of |.

[JordanMartinez]

Isn't this issue fixed now? Or is it still open because there is not yet a release with it included?

[TomasMikula]

Right, thanks.