Цитата:
|
Наверное по кнопке OK не диспатчить событие закрытия окна? Что за window - самописный?
|
Угу, самопал (за историю был написан не один), причем у писаного не мной аналога такие же проблемы.
Цитата:
|
А зачем здесь вообще каст. события? Я не знаю как вам лучше, но я бы ловил клик мыши, затем смотрел бы по какому объекту клик был сделан: если по ок - проверяем поле ввода имени пользователя и пр., если другое - закрываем окно, делаем что то другое...
|
Да Вы что? Код, запускающий диалог, будет копаться в его внутренностях? Там же концов не найдешь потом, во всяком случае автор такого подхода был жестоко замучен вопросами типа "Что здесь означает (event.currentTarget.parent as MyPanel).selectedValue?". И как-бы преимуществ нет никаких.
Цитата:
- можно добавить в ваш оконный класс параметр, дистпатчить ли CLOSE при закрытии, т.е в первом случае при клике вызываем hide(), во втором hide(false)
- можно в окне ставить флаг, что имя введено и при close узнавать у окна, введено ли имя (т.е. обойтись одним событием)
а вобще если все хотите обрабатывать в одном хендлере, как раз и будут получаться флаги и тому прочее, лучше слушать разные события, просто клик по крестику и кнопке "отменить" будут диспатчить одно событие, кнопка "ок" - другое
|
Т.е. в 2-х словах отразить состояние закрытия в поле окна? Может быть. Но что-то помешало мне принять такой варинат, не помню...
2 crazyone:
во-во, такой подход в последнем проекте используем. Только с целочисленными, а не строковыми ключами выхода. Т.е. функция закрытия базового окна принимает ключ закрытия, 0 - это крестик или Cancel, а что значат 1,2 и т.д. определяется в окнах-наследниках (в статических константах на классе окна).
Тут проблемы возникли с передачей чего-то большего, чем код возврата. Еще свичи смущают.
Видимо самый адекватный вариант взять эту схему и расширить метод close(closeCode) до close(closeCode:int, data:Object = null); С типизацией тут все равно лучше ничего не придумаешь, а свитчи - они не кусаются и в обработке закрытия диалогов ещё _не_ вредили.