On Wed, 26 Jul 2023 03:27:41 GMT, Prasanta Sadhukhan <[email protected]> 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. > > Prasanta Sadhukhan has updated the pull request incrementally with one > additional commit since the last revision: > > setDocument and test fix > > I wonder what happens if `setText` is called with a value that cannot be > > interpreted by the current formatter and how it plays with different > > policies on focus lost as outlined in [the > > javadoc](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFormattedTextField.html). > > ~It should be safe because `commitEdit` is guarded by `isEditValid`.~ > > I was about to write the above but I looked deeper in the code, and my > opinion has changed dramatically. > > Let's see what's happening when `setText` is called. The first thing that's > done is `super.setText` is called. So far, so good. > > The call `super.setText` mutates the text model, `Document`; as the result, > the `edited` flag is set to `true` by `DocumentHandler` and its > `insertUpdate` and/or `removeUpdate` methods. > > When is the text validated? When is `isEditValid` set to `true` or `false`? > The comment for the `setEditValid` method says, “This will invoked by > `AbstractFormatter` as the user edits the value.” I can't see where and when > `AbstractFormatter` gets called in this case. > > Things aren't as clear now… > > The documentation for > [`JFormattedTextField`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFormattedTextField.html#) > suggests the `setValue` method should be used to set the value. > > When you edit the value, the `setText` method is used to change the displayed > text as the `JFormattedTextField` switches into editing mode and back. As > such, changing the implementation of `setText` (and `setDocument`) adds an > overhead. > > It looks as if `setText` and `setDocument` as well as methods of `Document` > may mutate the text bypassing the formatter, thus breaking the invariants > provided by the `JFormattedTextField` class. Perhaps, if it were possible, > the direct access to `setText`, `setDocument` and `getDocument` should be > restricted. > > Taking into account everything I said above, I strongly believe the fix is > not necessary and the bug should be closed as either _Not an Issue_ or _Won't > Fix_. > > **The correct fix** to the sample provided is to _use the `setValue` method > instead of `setText`_. > > In `JFormattedTextProblem.java`, replace the lines > > ```java > dateField.setText(displayDate.format(new Date())); > timeField.setText(displayTime.format(new Date())); > ``` > > with > > ```java > dateField.setValue(new Date()); > timeField.setValue(new Date()); > ``` > > and both formatted text fields, `dateField` and `timeField`, behave as > expected. I tend to agree..Besides the fix is also causing couple of JCK test to fail as setText->commitEdit->setValue->setFormatter->format.install->setText causing StackOverflowError so seems like setValue, as you told, should be used instead.. Closing this as Not an Issue ------------- PR Comment: https://git.openjdk.org/jdk/pull/14993#issuecomment-1698515659
