Java 8 DatePicker 和可编辑的 ComboBox 行为在 8u51 和 8u60 之间发生变化

Question

我们已经广泛搜索了这个论坛和网络，但没有找到与此问题相关的任何内容，所以我觉得有必要在这里发布这个问题......

我们观察到在 Java 8 u51 和 u60 版本之间，JavaFX8 DatePicker 和可编辑的 ComboBox 元素的功能发生了重大的行为变化。

在 u51 下运行，您可以在 DatePicker 中输入一个日期，例如 12/30/1970 并跳转到下一个 U.I.元素和数据将自动保存，如果日期绑定(bind)到年龄计算 TextField，则年龄将更新。可编辑的 ComboBox 元素也是如此。但是，在 u60 下运行时，用户必须在 DatePicker 或可编辑组合框上的数据更改后按 ENTER，否则不会保存数据。切换到下一个 U.I.在 U.I. 之外的元素或鼠标单击元素和数据丢失，取而代之的是编辑之前保存在该元素中的内容。

所以我的问题是，有没有其他人注意到这个关键的行为变化，如果是，觉得这是 u60 中的一个错误，或者 Oracle 出于某种原因故意采取的方向？

最后是否有变通办法，也许采用事件处理程序的形式，可以模拟在这些元素失去焦点之前按下“ENTER”键？

提前感谢您的考虑。

Answer 1

ComboBoxPopupControl 的实现(它实际上是所有类似组合控件的相关基础皮肤)在 u40 和 u60 之间的某处发生了变化:textField - 包括所有内部布线 - 从具体皮肤(如 f.i. ComboBoxListViewSkin)中提取出来进入基地。

除了这个纯粹的技术性之外，ENTER 的处理程序也发生了变化:

• 是:将组合接收到的所有 keyEvent 转发给文本域
• 是:处理和使用基础皮肤中的 ENTER。此实现手动将字段中的输入文本提交给组合的值。

一个肮脏的(!因为需要访问内部包 com.sun.whatever.skin)出路是自定义皮肤，它监听 focusProperty 并调用提交方法，例如:

public class MyComboSkin<T> extends ComboBoxListViewSkin<T> {

    public MyComboSkin(ComboBox<T> comboBox) {
        super(comboBox);
        getSkinnable().focusedProperty().addListener((source, ov, nv) -> {
            if (!nv) {
                setTextFromTextFieldIntoComboBoxValue();
            }
        });
    }
}

应用自定义皮肤的优点是可以通过添加样式表在每个场景中应用一次:

// defining the skin in a css mycomboskin.css 
.combo-box {
    -fx-skin: "mypackage.MyComboSkin";
}

// apply to a scene
String commitCSS = getClass().getResource("mycomboskin.css").toExternalForm();
scene.getStylesheets().add(commitCSS);

// or to the application (using internal api again ;-)
StyleManager.getInstance().addUserAgentStylesheet(commitCSS) 

顺便说一句:我认为核心中的新实现相当脏——所有 keyBindings 应该要么在 XXBehaviour 中处理，要么留给较低级别​​的子级(比如 textField 本身)。行为的变化(针对 8u45 验证)可能被视为错误。

---

更新

另一种技巧是在组合的编辑器上使用 TextFormatter 并将其 valueProperty 双向绑定(bind)到组合的 valueProperty，例如:

TextFormatter formatter = 
        new TextFormatter<>(comboBox.getConverter());
comboBox.getEditor().setTextFormatter(formatter);
comboBox.valueProperty().bindBidirectional(formatter.valueProperty());

这确实有效，因为格式化程序保证提交 - 又名:将其自己的值同步到 textField 的文本 - 在 focusLost 上(更多细节在类似的 requirement for Spinner 中)请注意，这种方法的副作用是文本是 promise 下拉菜单内的导航，根据上下文，这可能是可接受的，也可能是 Not Acceptable 。此外，与专用解决方法相比，它更多地尝试使用 TextFormatters - 需要与 other solution by Scott 中的解决方法相同的每个实例操作。 .

---

bug已在 jdk9 中修复并向后移植到 8u72，因此任何变通方法都希望是短暂的，选择一次或其他并根据需要尽可能变脏可能是一个品味问题:-)