改变JFileChooser行为：阻止“选择”在文件路径JTextField中输入 [英] altering JFileChooser behaviour : preventing "choose" on enter in file path JTextField
问题描述
向Swing Pros致以问候，这是一个很好的（我希望）问题。
Greetings to Swing Pros, here's a good (I hope) question for you.
以下是我看到的任务要求和可能的解决方案。我想有人有这样的铁杆经验来分享一些关于这个的想法。
The below are the task requirements and possible solutions I see. I would like someone having had such a hardcore experience to share some thoughts about this.
这不需要编码或类似的东西，我只需要一般建议哪种方法更多关于我需要使用位于sun.swing和/或javax.swing.plaf包中的私有符号这一事实的可靠性。
This does not require coding or anything like that, I just need general advice as to which approach is more reliable regarding the fact I need to work with private symbols which reside in sun.swing and/or javax.swing.plaf packages.
任务是修改/改变JFileChooser行为（实际上只是一点点）。
The task is to modify/alter JFileChooser behaviour (just a little bit, actually).
-
当用户按下文件中的Enter时命名为JTextField，并且该字段包含dir的路径，不要选择dir，而是切换到它。是的，对话框配置为接受目录，但我们只需要接受打开按钮的点击，并且（可能）双击文件列表表。
when the user presses enter in the file name JTextField, and the field contains a path to a dir, don't "select" the dir, but switch to it instead. Yes, the dialog is configured to accept directories, but we need to accept only clicks on the "Open" button, and (possibly) double-clicks in the file listing table.
阻止用户通过在文件名文本字段中输入来选择数据超过1GB的目录/文件
prevent user from selecting a dir/file with more than 1GB data via hitting enter in the file name text field
以下是一些通用解决方案选项：
Here're couple of general solution options:
a。聆听JFileChooser提供的基于属性的更改（事后触发哪种AFAICS，并且不会提供我们需要的控制程度）。
a. listen on the property-based changes that JFileChooser provides (which AFAICS are triggered after-the-fact and won't provide the degree of control we need here).
b 。修改javax.swing.plaf.basic.BasicFileChooserUI（通过修改，打破私有级封装）并改变对
b. tinker with the javax.swing.plaf.basic.BasicFileChooserUI (via refrection, breaking the private-level encapsulation) and alter the reference to
private Action approveSelectionAction = new ApproveSelectionAction();
以便我们的自定义操作对1和2进行额外检查。这种方法与plaf包和如果在此UI类下面的某个类中以某种方式覆盖此操作，则可能会失败。
so that our custom action does the extra checks for 1 and 2. This approach links with plaf package and may fail in case this action is somehow overridden in some class below this UI class.
c。遍历JFileChooser组件层次结构，找到JTextField（显然应该只在组件树中出现一次），使用我们的自定义检查装饰挂在JTextField上的所有动作侦听器。我的调试会话显示这个JTextField是生活在sun.swing.FilePane中的JTextField的一些匿名子类。
这种方法似乎更加符合OO，但是对于某些操作系统来说，这个文本字段可能不存在，或者某些其他JTextField也存在于层次结构中。
c. traverse the JFileChooser component hierarchy, find the JTextField (which apparently should occur only once in the component tree), decorate all the action listeners hanging on that JTextField with our custom checks. My debugging session shows that this JTextField is some anonymous subclass of JTextField living in the sun.swing.FilePane. This approach seems to be more OO-friendly, but there's a chance that for some OS this text field is absent, or some other JTextField is also present in the hierarchy.
好吧，似乎公共JFileChooser API不足以实现这种行为，而其他两个选项要么是深度魔法还是不可移植（长期），要么两者兼而有之。
Well, it seems that public JFileChooser API would not suffice to achieve that behaviour, while the other two options are either deep magic or unportable (long-term), or even both.
所以，问题是：你会选择哪种方法？为什么？
So, the question is: which approach would you choose and why?
推荐答案
关于option2，您不需要使用反射来自定义accept Action。您可以覆盖approveSelection（）方法。类似于：
Regarding option2, you don't need to use reflection to customize the accept Action. You can just override the approveSelection() method. Something like:
JFileChooser chooser = new JFileChooser( new File(".") )
{
public void approveSelection()
{
if (getSelectedFile().exists())
{
System.out.println("duplicate");
return;
}
else
super.approveSelection();
}
};
这篇关于改变JFileChooser行为：阻止“选择”在文件路径JTextField中输入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
