Russian Qt Forum
Июля 07, 2025, 12:35 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: postEvent  (Прочитано 6321 раз)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« : Января 14, 2014, 09:58 »

Добрый день

Понял что события посланные с помощью postEvents будут обрабатываться до событий полученных от ОС (если не так - поправьте). Это именно то что мне нужно, но тут 2 детали

1) Утомительно отслеживать послал ли я уже какое-то событие или еще нет. Виртуальный метод QCoreApplication::compressEvent это решает, но он не документирован  Плачущий Нет ли чего-то "полегальнее"?

2) В каких-то ситуациях я не хочу обрабатывать событие которое я же себе и послал через postEvent. Как сделать чтобы оно осталось в очереди? Если такой возможности нет, то как пере-послать событие избегая зацикливания?

Спасибо
Записан
Fregloin
Супер
******
Offline Offline

Сообщений: 1025


Просмотр профиля
« Ответ #1 : Января 14, 2014, 10:58 »

на сколько я понимаю есть accept и ignore у событий. может в них есть подсказка. или же просто событие игнорировать и опять слать в postEvent?
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #2 : Января 15, 2014, 10:02 »

на сколько я понимаю есть accept и ignore у событий. может в них есть подсказка. или же просто событие игнорировать и опять слать в postEvent?
accept/ignore влияют на дальнейшую обработку события, но в любом случае событие удаляется после окончания всех обработок (так я вижу по исходникам). "Просто опять слать" - ну столь же просто оно опять извлекается, QEventLoop зацикливается.
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #3 : Января 15, 2014, 10:17 »

Можно попробовать такой финт.
Вместо отсылки сообщений сразу, тобавлять их в свою очередь. Настроить таймер на нулевой интервал, тогда он будет срабатывать после обработки всех событий Qt-очереди. А в его слоте уже посылать события из нашей очереди с помощью postEvent.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #4 : Января 15, 2014, 18:42 »

Можно попробовать такой финт.
Вместо отсылки сообщений сразу, тобавлять их в свою очередь. Настроить таймер на нулевой интервал, тогда он будет срабатывать после обработки всех событий Qt-очереди. А в его слоте уже посылать события из нашей очереди с помощью postEvent.
Пример: получено напр keyDown. К этому моменту необходимо чтобы все события посланные через postEvent были обработаны. Т.е. все должно быть синхронизировано, только тогда можно начинать следующие действия что вызовет обработчик keyDown. А таймер к этому моменту не успевает.

[/offtop]
Помню ох и влетел, чуть грыжу не нажил пока не разобрался
Код
C++ (Qt)
postEvent(MyEvent1...);
postEvent(MyEvent2...);
 
Какие здесь могут быть проблемы?  Улыбающийся
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #5 : Января 15, 2014, 19:06 »

К этому моменту необходимо чтобы все события посланные через postEvent были обработаны.

Мы пытаемся уйти от зацикливания.

"Просто опять слать" - ну столь же просто оно опять извлекается, QEventLoop зацикливается.

Как я понял: вы в обработчике event достаете событие, смотрите и решаете, что оно пока не нужно - делаете репост, выходите и тут же получаете это событие вновь, т.к. оно стало перед спонтанными событиями. Тогда не понятно, когда вы хотите, что бы это событие  было обработано?
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #6 : Января 15, 2014, 19:15 »

Как я понял: вы в обработчике event достаете событие, смотрите и решаете, что оно пока не нужно - делаете репост, выходите и тут же получаете это событие вновь, т.к. оно стало перед спонтанными событиями. Тогда не понятно, когда вы хотите, что бы это событие  было обработано?
Когда я разрешу (напр установлю флажок "обработка разрешена"). Если надо приведу пример подробнее
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #7 : Января 15, 2014, 19:20 »

Если надо приведу пример подробнее
Надо, а то не совсем понятно.
Очереди событий занимаются диспетчеризацией событий - добавление туда логики не очень хорошая идея.
« Последнее редактирование: Января 15, 2014, 19:22 от Old » Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #8 : Января 15, 2014, 19:58 »

Очереди событий занимаются диспетчеризацией событий - добавление туда логики не очень хорошая идея.
Это принципиально то же самое что QueuedConnection. Хорошо, пример

- пользователь выбрал неск объектов и передвинул их. Движение каждого вызывает серию действий, напр обновить его диалог (если открыт), пересчитать глобальный bounding box, перерисовать объект в окнах и много чего другого. Выполнять все эти действия немедленно никак не годится, поэтому забрасываем их в очередь событий. Конечно событие может породить др события, но все они будут выполнены до след активности юзера. Все хорошо работает

- теперь выясняется что само исходное действие может быть долгим и без обработки событий не обойтись - ну хотя бы Cancel нужен. Но при первой же попытке processEvents засланные события начнут выполняться, все рухнет.

Как грамотно разрулить эту ситуацию?
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #9 : Января 15, 2014, 20:19 »

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

Может для отправки событий использовать свою функция, которая при запрещающем флаге будет помещать событие не в системную очередь, а в свою. А при установке разрешающего флага выталкивало все события из своей очереди в системную.
Записан
Racheengel
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2679


Я работал с дискетам 5.25 :(


Просмотр профиля
« Ответ #10 : Января 15, 2014, 22:03 »

Igors, а можно немного оффтопа...
вам сейчас приходится виндовое приложение на Qt портировать, что ли? Улыбающийся
А то много эвентов что-то туда-сюда ходят...
(спрашиваю, потому что подобное предстоит скоро, наверное)

Записан

What is the 11 in the C++11? It’s the number of feet they glued to C++ trying to obtain a better octopus.

COVID не волк, в лес не уйдёт
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #11 : Января 16, 2014, 15:32 »

В том то и дело, что не то же самое. Улыбающийся
В случае QueuedConnection события ставятся в очередь и выполняются согласно поступления.
Вы же хотите заставить очередь еще анализировать события и запрещенные к обработке оставлять на потом.
Не только - еще у меня есть приоритеты, да и вообще я сигналы-слоты не люблю  Улыбающийся Ну я говорил "в принципе"

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

вам сейчас приходится виндовое приложение на Qt портировать, что ли? Улыбающийся
Почти - нативное приложение OSX, ну в Вындоуз тоже предстоит нырять  Плачущий
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.033 секунд. Запросов: 23.