Написал класс фильтра событий. Одна загвоздка: метод перехвата в фильтре событий требует, чтобы тип второго параметра был QEvent, иначе он просто не перехватывает событие. А в типе QEvent нет возможности передать сопроводительную информацию.

Я попробовал создать производный класс, наследника от QEvent, (с дополнительными членами) и передавать объекты этого класса. но тогда в обработчике фильтра события нет возможности обратиться к нужным членам (иначе ругается компилятор).

Как выкрутиться?

egorychdynamic_cast спасёт ОРД =))

Можно чуть- чуть подробнее? Что вы имеете в виду?

egorychdynamic_cast спасёт ОРД =))

Спасибо, динамическое приведение типов помогло!

egorychegorych, сорри, накосячил с квотированием

Пардон, а можно узнать что такое квотирование и как вы с ним накосячили?

White OwlУбери немедленно!
Если ты работаешь с Qt, то надо использовать qobject_cast. Оно "роднее", не требует RTTI, переносимее, и как ни странно - быстрее чем dynamic_cast.

Спасибо, изучу вопрос.

egorychWhite OwlХотя, я вообще сомневаюсь что исходную задачу надо решать. Как-то не могу придумать зачем в фильтре делать собственный класс событий. AlekseySQL, тебе мало QEvent::type = QEvent::UserType+X ?вот с этим я согласен. Предполагаю даже, что и события ему не нужны, сигналов со слотами, вероятно, будет достаточно

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

Сигналы и слоты при межпоточном взаимодействии транслируются в события (с созданием лишних объектов через new/delete, что при многопоточной работе очень плохо). Поэтому мое решение более масштабируемо.

Про повышение масштабируемости я конечно загнул. Все- таки изменение масштабируемости подразумевает качественные изменения, а в моем случае изменения всего навсего количественные. К тому же не факт, что при трансформации сигнала в событие будет использовано два и более объекта.

egorychоткуда дровишки?

Шлее М. "Qt 5.3. Профессиональное программирование на C++", примечание на стр 546.

White OwlИ почему вдруг стандартного QEvent не хватает?
Что именно ты передаешь в ГУИ-поток? Процент выполнения задачи дочерним? Или текст что мол дочерний находится на таком-то этапе? Или что-то более сложное?
Первые две задачи решаются элементарно: дочерний поток кидает главному событие которое имеет смысл: "у меня есть обновление". Главный читает shared переменную принадлежащую этой дочке и показывает значение этой переменной юзеру. Все.

Дочерних потоков много, поэтому при вашей реализации необходимо создать различные события для каждого потока (нужен какой-то менеджер QEvent ID). Также необходим потокобезопасный вектор с данными QString, в котором будет храниться информация из дочерних потоков.

Не проще ли все трудности многопоточности переложить на потокобезопасный postEvent() от ребят из Qt? В этом случае параллельно посылаемые события уже будут выстроены последовательно в основном потоке, останется их только обрабатывать.

[quot White OwlА сколько у тебя этих событий происходит? В секунду? В минуту? Ты уверен что то, что ты отмел как "очень плохо", на самом деле является всего-лишь "не абсолютно идеально"? Не забывай что человек не в состоянии прочитать текст появляющийся на экране на миллисекунду. На практике, даже прогресс-бар надо обновлять не чаще чем три раза в секунду, а тексты желательно не чаще чем раз в две-три секунды. Иначе ты просто зря потратишь ресурсы.[/quot]

Согласен, код интерактивного взаимодействия с пользователем оптимизировать не нужно. Передача информации юзеру тоже работа с пользователем. А сигналами/слотами можно передать дополнительную информацию? Что-то я такого не встречал (хотя и глубоко этот вопрос не изучал).