изменение поведения JFileChooser: предотвращение «выбора» при вводе в путь к файлу JTextField
Приветствую Swing Pros, вот хороший (я надеюсь) вопрос для вас.
Ниже приведены требования к задачам и возможные решения, которые я вижу. Я хотел бы, чтобы кто-нибудь, у кого был такой жесткий опыт, поделился своими мыслями по этому поводу.
Это не требует кодирования или чего-то подобного, мне просто нужен общий совет относительно того, какой подход более надежен в отношении того факта, что мне нужно работать с частными символами которые находятся в пакетах sun.swing и / или javax.swing.plaf.
Задача состоит в том, чтобы изменить / изменить поведение JFileChooser (на самом деле, совсем немного).
когда пользователь нажимает Enter в имени файла JTextField , и поле содержит путь к каталогу, не «выбирайте» каталог, а вместо этого переключитесь на него. Да, диалоговое окно настроено для приема каталогов, но нам нужно принимать только щелчки по кнопке «Открыть» и (возможно) двойные щелчки в таблице списка файлов.
запретить пользователю выбирать каталог / файл с большим количеством данных размером более 1 ГБ, нажав Enter в текстовом поле имени файла
Here ' В отношении пары общих вариантов решения:
a. прислушивайтесь к изменениям на основе свойств, которые предоставляет JFileChooser (которые AFAICS запускаются постфактум и не обеспечивают необходимую степень контроля)
b. поработать с javax.swing.plaf.basic.BasicFileChooserUI (с помощью исправления, нарушив инкапсуляцию частного уровня) и изменить ссылку на
private Action approveSelectionAction = new ApproveSelectionAction();
, чтобы наше настраиваемое действие выполняло дополнительные проверки для 1 и 2. Этот подход связан с plaf пакет и может потерпеть неудачу в случае, если это действие каким-либо образом переопределено в каком-либо классе ниже этого класса пользовательского интерфейса.
c. пройти по иерархии компонентов JFileChooser, найти JTextField (который, по-видимому, должен встречаться только один раз в дереве компонентов), украсить все прослушиватели действий, висящие на этом JTextField, с помощью наших пользовательских проверок. Этот подход кажется более удобным для объектно-ориентированных приложений, но есть вероятность, что для некоторых ОС это текстовое поле отсутствует или в иерархии присутствует какое-то другое поле JTextField.
Что ж, похоже, что общедоступного API JFileChooser недостаточно для достичь такого поведения, в то время как два других варианта либо глубокая магия, либо непереносимость (долгосрочная), либо даже то и другое.
Итак, вопрос: какой подход вы бы выбрали и почему?