Проверка JList до выбора происходит

Question

В настоящее время у меня есть прослушиватель выбора списка прослушивания JList.

private void jList1ValueChanged(javax.swing.event.ListSelectionEvent evt) {
    // When the user release the mouse button and completes the selection,
    // getValueIsAdjusting() becomes false        
    if (evt.getValueIsAdjusting()) {
        /*
          In certain situation, I may want to prevent user from selecting other
          than current selection. How can I do so?
        */
    }
}

В определенных ситуациях я могу запретить пользователю выбирать другой вариант, кроме текущего. Как я могу это сделать?

Кажется, слишком поздно, когда я получаю ListSelectionEvent. Но если я хочу сделать это до того, как произойдет ListSelectionEvent, я не знаю, что пользователь пытается выбрать другое.

Вот один из сенарио.

JList содержит список названий проектов. Таким образом, всякий раз, когда пользователь выбирает новый элемент списка, нам нужно повернуть представление из текущего проекта и отобразить новый проект. Тем не менее, текущий проект может быть еще не сохранен. Следовательно, если текущий проект еще не сохранен, мы запросим подтверждение пользователя "Сохранить проект?" (Да, Нет, Отмена) Когда пользователь выбирает «Отмена», это означает, что он хочет отменить действие «Выбрать другой проект». Он хочет придерживаться текущего выбора JList. Мы откроем диалоговое окно подтверждения в дескрипторе события jList1ValueChanged. Но когда мы пытаемся придерживаться текущего выбора JList, уже слишком поздно.

Answer 1

Я реализовал это следующим образом для того же варианта использования рабочего процесса. Хотя это работает достаточно для меня, я бы хотел, чтобы был более простой и элегантный подход, при котором на событие отбора можно было наложить вето, прежде чем продолжить. Если у меня будет время изучить и выяснить это, я сделаю репост, но это может расцениваться как случай, когда окупаемость инвестиций не стоит (т.е. настройка классов Swing, непосредственная обработка событий мыши / клавиатуры более низкого уровня и т. Д.). В любом случае, в настоящее время я сохраняю последний удачный «проверенный» выбор и возвращаюсь к нему, если пользователь отменяет будущий выбор. По общему признанию это не самое симпатичное решение, но оно работает:

// save the last good (i.e. validated) selection:
private ProjectClass lastSelectedProj;

// listing of available projects:
private JList list;

// true if current selected project has been modified without saving:
private boolean dirty;

list.addListSelectionListener(new ListSelectionListener() {
    public void valueChanged(ListSelectionEvent evt) {

    if (evt.getValueIsAdjusting()) return;

    // first validate this selection, and give the user a chance to cancel.
    // e.g. if selected project is dirty show save: yes/no/cancel dialog.
    if (dirty) {
        int choice = JOptionPane.showConfirmDialog(this,
            "Save changes?",
            "Unsaved changes",
            JOptionPane.YES_NO_CANCEL_OPTION,
            JOptionPane.WARNING_MESSAGE);

        // if the user cancels the selection event revert to previous selection:
        if (choice == JOptionPane.CANCEL_OPTION) {
            dirty = false; // don't cause yet another prompt when reverting selection
            list.setSelectedValue(lastSelectedProj, true);
            dirty = true;  // restore dirty state. not elegant, but it works.
            return;
        } else {
            // handle YES and NO options
            dirty = false;
        }
    }

    // on a validated selection event:
    lastSelectedProj = list.getSelectedValue();

    // proceed to update views for the newly selected project...
}
}

Answer 2

  table.setSelectionModel(new DefaultListSelectionModel(){

   @Override
   public void setSelectionInterval(int index0, int index1) {

    if (dragState==0 && index0==index1 && isSelectedIndex(index0)) {
     // Deny all clicks that are one row & already selected
     return;
    } else {
     super.setSelectionInterval(index0, index1);
    }
   }

  });

Answer 3

Я бы посоветовал вам внедрить пользовательский ListSelectionModel.

Answer 4

Я думаю, вам нужно переопределить метод setSelectionInterval (...) JList, чтобы ничего не делать в ваших особых ситуациях.

Обработка на уровне события слишком поздняя, ​​поскольку событие уже произошло.