Запретить скрытие окна верхнего уровня, (без наследования) Опции

[hoRUS]

Можно ли как-нибудь запретить скрытие окна верхнего уровня (когда откуда-нибудь вызывается метод hide() или setVisible(false)), не наследуя класс окна и не переопределяя в вирт. функцию setVisible(bool) ?
Хотелось бы реализовать это с помощью фильтра событий... Но, к сожалению, событие QHideEvent высылается, когда окно уже скрыто.

P.S. Исходная задача - анимировать появление/скрытие различных окон.

Спасибо.

[ilyabvt]

Исходная задача - анимировать появление/скрытие различных окон.

Если вы имели ввиду сворачивание/разворачивание окна (а это главный источник спонтанного вызова события QHideEvent), то есть QWindowStateChangeEvent.

[wiz29]

Платформонезависимых решений мне не известно.

[hoRUS]

Если вы имели ввиду сворачивание/разворачивание окна

Да нет, хотелось бы перехватывать и обрабатывать по-своему именно неспонтанные события скрытия (hide) именно ДО того, как окно реально скроется. Т.е. те скрытия, которые явно программно вызываются с помощью hide() или setVisible(false). Причем неважно, откуда эти вызовы делались - из своего кода или из недр Qt.
Но, видимо, без наследования тут не обойтись. Пока решил проблему, заключив необходимую функциональность максимально в отдельный класс и передав объект этого класса во владение окну, скрытие кот. нужно анимировать. В вирт. ф-ции setVisible() анимируемого окна вызываю нужные методы этого отдельного класса. Это имхо лучше, чем копипастить код в разные классы окон верхнего уровня, главные окна и диалоги, но решение с фильтром событий было бы элегантнее...

[wiz29]

решения с фильтрами, по моему мнению, приводят к нечитабельности кода программ, старайтесь этого избегать)

[hoRUS]

решения с фильтрами, по моему мнению, приводят к нечитабельности кода программ, старайтесь этого избегать)

Почему же? Они часто позволяют сконцентрировать какую-то функциональность в одном единственном месте, избегая избыточного "копипастенья". Разве что иногда метод eventFilter() слишком длинным. Но ведь его можно разбить на несколько вызовов и сделать все достаточно читабельным...

[wiz29]

Дело в том что фильтром может быть любой QObject, тем самым скрывать прозрачность реализации.
Когда что то пишешь один то это не принципиально, но для разработки в команде бывают не очевидные применения встраивания функционирования объекта. Но еще раз повторю, это мое мнение.

Сообщение отредактировал wiz29 - 6.4.2012, 13:02

[hoRUS]

Дело в том что фильтром может быть любой QObject, тем самым скрывать прозрачность реализации.
Когда что то пишешь один то это не принципиально, но для разработки в команде бывают не очевидные применения встраивания функционирования объекта. Но еще раз повторю, это мое мнение.

Согласен. Решением тут может быть создание QObject'ов, специально предназначенных для фильтрации событий (и ни для чего более). И указание этого, в частности, в имени соответветствующего класса. Но что-то нас понесло в оффтоп.