RFR: 5032471: JFormattedTextField does not use editformatter on initial focus with setText()

Alexey Ivanov aivanov at openjdk.org
Tue Jul 25 11:20:48 UTC 2023


On Mon, 24 Jul 2023 09:20:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When a JFormattedTextField field value is set by setText, then when the field initially gains focus it seems to not use the edit formatter, but rather use display formatter, which is wrong. 
> Native "Date and Time setting" in windows changes the date field to edit mode in initial focus itself.
> Fix is made to treat setText as in edit mode and commit the changes made to it.

The bug report mentions using `setDocument()` to change the value of the formatted text field. Also, it's possible to call `getDocument().setText()`, which may still have the original bug.

src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 747:

> 745: 
> 746:     @Override
> 747:     public void setText(String text){

Shall the explicit `{@inheritDoc}` be added? Or rather the javadoc should be modified to reflect *the updated behaviour*. There are cases where the text isn't set, right?

src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 752:

> 750:             try{
> 751:                 commitEdit();
> 752:             } catch(ParseException pe){}//do nothing, we assume this will never happen.

Suggestion:

            } catch (ParseException ignored) {
                // Do nothing, we assume this will never happen
            }

This way would avoid a warning by IDEA.

test/jdk/javax/swing/JFormattedTextField/JFormattedTextProblem.java line 60:

> 58:             Robot robot = new Robot();
> 59:             robot.setAutoDelay(100);
> 60:             JFormattedTextProblem test = new JFormattedTextProblem();

The constructor should be called on EDT because it creates lots of Swing components and Swing components are not thread-safe.

test/jdk/javax/swing/JFormattedTextField/JFormattedTextProblem.java line 68:

> 66:             robot.keyPress(KeyEvent.VK_TAB);
> 67:             robot.keyRelease(KeyEvent.VK_TAB);
> 68:             if (!expected) {

Isn't `robot.waitForIdle()` required here to allow the EDT to handle all the events?

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

PR Review: https://git.openjdk.org/jdk/pull/14993#pullrequestreview-1545194304
PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273367125
PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273363168
PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273368884
PR Review Comment: https://git.openjdk.org/jdk/pull/14993#discussion_r1273369591



More information about the client-libs-dev mailing list