Диалоговое окно с ошибкой не уничтожается

Я работаю над проектом, который использует JTable для отображения, среди прочего, столбца дат. Нам нужна была проверка ввода данных пользователем для дат, поэтому я реализовал комбинацию маскирования для проверки формата и синтаксического анализа для проверки фактической даты. Я сделал это, используя пользовательский CellEditor для столбца даты.

Внутри моего MaskedCellEditor у меня есть JFormattedTextField. Я настраиваю маскировку для дат. Затем я добавляю InputVerifier для фактической проверки. В моем InputVerifier реализована функция verify() для проверки: 1. textField.isEditValid() 2. DateValidator.ValidDate(). Если любой из них недействителен, verify возвращает false, и InputVerifier блокирует фокус в текстовом поле (редактор ячеек), и отображается небольшое диалоговое окно с напоминанием пользователю о формате даты.

Сообщение об ошибке представляет собой небольшой недекорированный немодальный JDialog без фокуса, который появляется под редактируемой ячейкой. Он исчезает при нажатии клавиши или успешной проверке даты. Он отлично работает, за исключением небольшого краевого случая.

Если пользователь выбирает кнопку меню в верхней части приложения, в то время как в диалоговом окне появилось недопустимое редактирование, он переключает экраны, уничтожая все, что в данный момент находится на экране (включая таблицу). Однако, поскольку диалоговое окно отображается, а нажатие клавиши/успешное редактирование не произошло, диалоговое окно никогда не скрывается. Он остается видимым в совершенно не связанном контексте на другом экране. Как только пользователь выключил экран с таблицей, у пользователя нет возможности избавиться от диалога.

Я обсуждал добавление таймера и/или MouseListener в само диалоговое окно, что могло бы привести к его исчезновению, но я чувствую, что игнорирую реальную проблему. Диалог никогда не удаляется, и я уверен, что это потому, что он по-прежнему настроен на видимость и не позволяет сборщику мусора избавиться от него.

У меня есть метод очистки на панели, содержащей JTable, но я не могу найти хороший способ сослаться на диалоговое окно (компонент InputVerifier), чтобы избавиться от него. Диалог находится довольно далеко от родительской панели таблицы. (Панель -> JTable -> CellEditor -> JFormattedTextField -> InputVerifier -> JDialog)

Любые идеи о том, как скрыть диалоговое окно при уничтожении таблицы? Если вам нужна дополнительная информация, дайте мне знать. Я пытаюсь не утомлять вас, ребята, деталями, но там много всего происходит.


person Saterus    schedule 05.01.2009    source источник


Ответы (2)


В качестве первой мысли, вы не можете пойти вниз по подходу слушателя. Если у вас есть метод типа closeErrorDialog(), который вызывается при успешной проверке, вы также можете вызывать его при выборе действия меню.

В качестве альтернативы, возможно, вы могли бы каким-то образом контролировать переход из меню в меню и создать метод «очистки», который закроет все существующие диалоговые окна ошибок. Это позволит выполнять любые другие действия, которые необходимо выполнять при смене меню, в одном и том же месте.

Просто пара быстрых идей в верхней части моей головы. Надеюсь, они совпадают с тем, что вы имели в виду

person chillysapien    schedule 06.01.2009

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

person Paul Tomblin    schedule 05.01.2009
comment
Это не модальный тип диалога. Он не всплывает и не блокирует использование. Это больше похоже на всплывающую подсказку, которая показывает пользователю правильный формат. Он появляется прямо под ячейкой редактирования. Он не украшен (нет кнопок свернуть, развернуть, закрыть) и не фокусируется (если пользователь нажимает на него, ничего не происходит). - person Saterus; 06.01.2009
comment
Затем вам нужен какой-то хук, чтобы код меню мог отменить сопоставление объекта перед переключением с этого экрана. - person Paul Tomblin; 06.01.2009