java - 当我们选择“刷新”选项时，JFileChooser中的“修改日期”字段不会更新

Question

我正在使用JFileChooser来浏览文件。我已将视图选择为“详细信息”。在详细模式下，文件在四列下列出。名称，大小，项目类型，修改日期。当我修改JFileChooser当前正在显示的文件时，如果我右键单击并选择刷新选项，则“日期修改”字段不会以新时间更新。

但是，当我回到一个文件夹级别并返回时，“日期修改”字段将使用新时间进行更新。

解决这个问题的方法是什么？这是一个错误吗？？？

我正在使用NetBeans 8.0及其摆动的GUI Builder。

请帮忙。

谢谢

Answer 1

编辑：我删除了旧的答案，因为它是不正确的。

说明

您提到您正在使用NetBeans的GUI构建器。在没有看到生成的代码的情况下，我只能推测正在发生的事情。推测一下，我想是的，NetBeans的GUI构建器对此有过错-但是，根据您的观点，然后您也可能有过错。

一个好的经验法则永远都不要使用GUI构建器，尤其是在Swing中。首先，代码生成是一项艰巨的任务，但是Swing比大多数框架要复杂得多，这使Swing代码生成变得更加糟糕。本质上，您可以将Swing GUI构建器看作是一个糟糕的入门级开发人员，无论代码多么难以维护或多么糟糕，他都将尽其所能使它工作。这样做的问题是，当出现问题时（如您遇到的问题），您不仅需要知道Swing才能知道要查找的内容，而且还必须调试以前从未看过的代码，并且可能会花大量时间来理解，但是现在您要调试的代码非常糟糕。您确实需要手动创建GUI。

话虽如此，当我继续推测您的问题是因为您没有发布代码时，我猜测您试图操纵JFileChooser的外观……这是正确的吗？如果没有，我建议您更新问题。

如果是这样，那就是您的问题。对您来说似乎很明显，您在UI中查看的JFileChooser是包含代码中所有JComponents和Objects的JFileChooser。不幸的是，这是非常错误的（我是否提到Swing很复杂？）。

您正在查看的JComponent实际上是FileChooserUI对象的一部分。如果我没有记错的话，那么任何操作系统的默认FileChooserUI都是javax.swing.plaf.metal.MetalFileChooserUI（至少是我的本地测试的默认设置，而且我认为我从未见过如此不同的地方）我已经使用了JFileChooser）。供您参考，这是未修改的MetalFileChooserUI：


现在，我提到所有这一切，因为听起来好像您通过拖放东西来修改了JFileChooser的外观。由于所有JComponent实际上都存储在FileChooserUI中，而不是JFileChooser本身中，因此您实际上所做的是修改FileChooserUI。通过这样做，我敢打赌NetBeans创建了MetalFileChooserUI（或您正在使用的任何FileChooserUI）的新子类。将新UI安装到JComponent的方法是调用ComponentUI#installUI。不过，这似乎有一个缺陷。我还无法确切地知道此缺陷如何成为刷新问题，但我有猜测。无论哪种方式，我都会以一般方式解释这是一个问题。

基本上，当您调用installUI时，它将使您实际看到的UI看起来像您告诉它的方式。但是，ComponentUI对象在JFileChooser类中存储了对自身的引用，并且在安装新的UI时，旧的引用不会被新的UI对象覆盖。当您尝试刷新时，您的JFileChooser对象与ComponentUI对象之间似乎存在某种交互，并且我认为当它需要进行任何类型的更新时，它仍在调用旧的ComponentUI参考。

解决方案

这里有两种解决方案。

解决方案1

首先是在使用UIManager#put(java.lang.Object, java.lang.Object)创建JFileChooser之前，将外观设置为所需的ComponentUI对象，其中第一个参数是要更改的UI的名称（在本例中为'FileChooserUI'，第二个参数是您要使用的ComponentUI对象的完整类路径的字符串表示形式。在进一步介绍之前，我先说说我无法使其正常工作，而且我的外观似乎从未得到过您应该能够执行以下操作：

UIManager.put("FileChooserUI", "com.my.classpath.to.MyNewFileChooserUI");
new JFileChooser().showDialog(null, "FOO");

并且JFileChooser将使用com.my.classpath.to.MyNewFileChooserUI中的外观显示。它的工作方式是创建JComponent时，它会转到UIManager并询问应使用哪种外观，然后实例化它找到的类。您可以在JComponent文档中阅读有关此内容的更多信息。正如我所说，我从未能够做到这一点。

解决方案2

我已经开始工作的解决方案是做一些小小的修改。客观地讲，我什至不喜欢这种解决方案，如果解决方案1有效，我会说绝对不要这样做。由于我不知道解决方案1，因此我将告诉您我唯一可以使用的方法：

JFileChooser fc = new JFileChooser();
MyCustomFileChooserUI fcUI = new MyCustomFileChooserUI();
try{
    Method method = JComponent.class.getDeclaredMethod("setUI", javax.swing.plaf.ComponentUI.class);
    method.setAccessible(true);
    method.invoke(fc, fcUI);
} catch (Exception ex) { /*catch whatever you want and handle it however you want*/ }
fc.showDialog(null, "FOO");

这里发生的是，我正在调用一个受保护的函数。此函数将为您安装ComponentUI，并覆盖对象内部的旧ComponentUI参考。因此，当JFileChooser要通过引用访问外观时，现在将确保它访问正确的外观对象。这就是我所猜测的问题；试图“刷新”显示文件的外观内的JList时，它正在访问旧的ComponentUI参考。

免责声明

我这里没有谈论一些事情，例如如何重写ComponentUI对象，因为我认为这有点超出范围。另外，由于我提供的问题很少，因此这是我推测的很长的详细答案。另一个经验法则：您在问题中提供的详细信息越少，希望帮助您的人就越少，而这样做的人可能会给您提供您所不需要的答案，因为他们不知道您的意思想。