On Wed, 8 Feb 2023 18:12:40 GMT, Alexander Zuev <kiz...@openjdk.org> wrote:
>> So if I go back and look at the code before your previous fix, there was no
>> check,
>> so the timer is created and then I'd expect applies when the caret is
>> installed on a component.
>> Here that behaviour is changed, so that if we create a caret, then call
>> setBlinkRate(), and then install()
>> then the blink rate appears to be ignored whereas before 4512626 it was
>> applied.
>
>> if we create a caret, then call setBlinkRate(), and then install()
>> then the blink rate appears to be ignored whereas before 4512626 it was
>> applied.
>
> Ok, if the text component is already visible and editable and focused and we
> install the new caret then the blink rate will not have an effect until the
> focus is lost and regained or until it became non-editable - and i think that
> was close to what we had before and there is a bug to investigate and
> optimize such corner case. In all other cases the code works fine. The value
> set is being preserved and will be reactivated when any of the methods such
> as focusGained or when the component installUI is called - if the cursor is
> set before component becomes visible - will cause to re-evaluate the blink
> rate and the stored value set by user will take place.
Suppose I have this code
Caret c = new DefaultCaret()
c.setBlinkRate(50);
c.install(editableJComponent);
BEFORE 4512626 the JDK code looked like this
if (rate != 0) {
if (flasher == null) {
flasher = new Timer(rate, handler);
}
flasher.setDelay(rate);
}
With your fix it looks like this
if (rate != 0) {
if (component != null && component.isEditable()) {
if (flasher == null) {
flasher = new Timer(rate, handler);
}
}
}
So with my sample application code there's a change that my blink rate is
completely lost.
-------------
PR: https://git.openjdk.org/jdk20/pull/122
