Как очичтисть очередь событий для конпки
В программе есть длительная операция (может достигать 50 сек.).
Во время этой операции вызываю Dialog{ modal: true }. В диалоговом окне прогресс бар и кнопка закрытия окна,
у которой enabled: false. По окончанию операции кнопке закрытия ставлю enabled: true.
Если во время дляительной операции нажать кнопку закрытия на диалоговом окне,а потом любую другую кнопку или объект в главном окне программы, то после окончания операции, как только ставлю кнопеке enabled: true, диалоговое окно закрывается и происходит обработка остальных нажатий. Т.е. получается, что события накапливаются в очереди и обрабатываются позже.
Собственно вопрос, как очисть события для кнопки до установки enabled: true?
Upd. пробовал QCoreApplication::removePostedEvents(nullptr) эффекта нет.
Рекомендуем хостинг TIMEWEB
Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.Ол саған ұнайды ма? Әлеуметтік желілерде бөлісіңіз!
Пікірлер
- Ora Iro
- Жел. 24, 2024, 6:38 Т.Ж.
C++ - Тест 001. Первая программа и типы данных
- Нәтиже:40ұпай,
- Бағалау ұпайлары-8
- Akiv Doros
- Қар. 11, 2024, 2:58 Т.Қ.
C++ - Тест 004. Указатели, Массивы и Циклы
- Нәтиже:50ұпай,
- Бағалау ұпайлары-4
- molni99
- Қаз. 26, 2024, 1:37 Т.Ж.
C++ - Тест 004. Указатели, Массивы и Циклы
- Нәтиже:80ұпай,
- Бағалау ұпайлары4
не нужно очишать очередь, нужно, писать приложение многопоточным через qthread или qconcurrent
Каким образом открыть модальное диалоговое окноно в QML из другого потока?
Не понимаю, зачем в данном случае многопоточность, нужно просто, чтобы кнопка, когда она не активна не принимала события.
нужно сделать связку qml и c++, тяжелые задачи отправляются на обработку в с++, в qml остаются только быстрые.
и у кнопок есть свойство
enabled: true\false
при запуске\остановке задачи нужно задать соответсвующее занчение этого параметра.
на QML только QUI, остальное в C++, что нужно выведено в отдельный поток, при чем тут это?
После установки у кнопки enabled: true происходит обработка нажатия, которое блыо сделано пока кнопка была неактивна (enabled: false), закрывается диалоговое окно и обрабатываются остальные нажатия, причем все, которые сделал.
явно, что-то идет не так.
этого не может быть.
хорошо бы предявить исходный код.
Я думал, что сигналы к неактивным эффектам должны отбрасываться, а не копиться в очереди.
Попробую на досуге сделать минимальный тестовый проэкт.
ок
Тестовый проект сделал, но на нем все работает нормально.
Причину нашел, во время операции есть функция ожидания, в короторой такой код:
ost.vld - спасибо за помощь
читаю с первого поста.... ни чего не понятно.... это конечно хорошо, что у вас проблема решилась. Но....
1. "В программе есть длительная операция (может достигать 50 сек.). Во время этой операции вызываю Dialog{ modal: true }." - т.е. эта длительная операция выполняется в gui потоке?
"В диалоговом окне прогресс бар" - как происходит обновление/переисовка бара?
"кнопка закрытия окна, у которой enabled: false" + "Если во время дляительной операции нажать кнопку закрытия" - а как такое возможно? Как можно даже теоретически нажать дизейбленную кнопку? Что такое "нажать кнопку"? Есть разные способы (мышкой, клавиатурой, палец+тачскрин, ....) - "нажать кнопку" (будем считать, что кнопка без фиксации) - это значит передать ей фокус, перевести её в состояние "нажатая" и перевести её в состояние "отжатая" - вот тогда это будет считаться "нажали кнопку". Как вы умудрились задезейбленую кнопку перевести в состояние "нажатая"? Может всё таки вы не "нажали кнопку", а кликнули мышкой по неактивной кнопке?
..... ещё есть вопросы конечно.... взглянуть бы на исходный код. Вам бы быстрее помогли, на и вопросов бы было мнеьше.
По сигналу прогрессбар обновляется.
Кнопка прорисована, но не активна, нажимаешь мышкой, естественно ничего не происходит.
Но как только ставишь enabled: true, то происходит обработка нажатия
Весь проект скинуть не могу, поэтому так, изначально подумал, что поведение штатное и есть решение.
Оказалось, что побочный эффект.
Длительная операция, прошивка устройства, протокол обмена продиктован устройством, повлиять на него никак не могу.
Данные передаются пакетами по 2 КБ, потом от устройства приходит ответ, что все получено и т.д.
Ответ приходит через callback, поэтому и нужна функция ожидания: или пришел ответ и данные передаются дальше, или ответа нет и передача данных прерывается. Собственно во время ожидания и запускал loop.exec(QEventLoop::ExcludeUserInputEvents);
Перепишу все на сигналах с таймером.
я делал подобные задачи... чтоб не возиться с потоками - всю передачу вел в потоке GUI. т.е. по кнопке "Burn" вызывался слот и прямо в слоте дизаблил виджеты, в цыкле делал прошивку (отправку и прием данных) и задавал значения прогрессБару, после цыкла енаблел виджеты. Естественно если так сделать, то гуи не перерисуется до выхода из слота. И все клики по кнопкам накопятся и отработаются после прошивки. Чтобы не копились события, чтобы во время длительной операции перерисовавался прогресс и перерисовывались (дазабле/енабле) кнопки и виджеты, в цыкле отправки/ожидания данных нужно переодически вызывать
QCoreApplication::processEvents(QEventLoop::AllEvents);
Да, может не совсем хороший способ в GUI потоке делать медленную переправку данных, но для мелких поделок разводить кучу дополнительных потоков и переплетение их сигналами/слотами, да ещё и таймера - это оверинженеринг. А так, можно по быстрому что-то простое сделать. Визуально это будет выглядеть как "работа GUI" в своем потоке, "примем/отправка данных" в своем потоке.
вот это надо протестировать
Тут согласен, в моем случае во время записи, кроме самой записи только перерисовка GUI и нужна.