Не работает выход из консольного Qt приложения
Не завершается консольное приложение в функции App::replyError() , хотя при ошибке в функцию заходит, и сообщение выводится. В App::run() все нормально.
PS: Делаю первые попытки в Qt. Сильно говнокодно?
Рискну предположить, что цикл обработки сообщений не успел стартануть до вызова replyError , хотя, по идее так быть не должно и это похоже на баг.
Если тебе ехать — сделай через postEvent , если шашечки — то смотри код exit и код exec . exit где-то должен проверять что «ивент луп запущен».
Есть ещё вероятность, что разработчики таймера считерили и сделали для сна 0 вызов в обход цикла событий. Это в любом случае баг, но попробуй выставить таймаут у таймера в единицу.
для сна 0 вызов в обход цикла событий
нет, в ближайший свободный таймслот евентлупа. об этом даже в документации написано.
ну, так.. нормальненько 😀
зачем ты еще один евентлуп себе нагородил?
вот эта штука return application.exec(); уже запускает основной вентлуп и, в общем случае, тебе другой такой не нужен.
Я про реализацию.
Спасибо, вы дали направление для решения проблемы.
Дополнительный QEventLoop нужен для реализации сетевого запроса в синхронном стиле. Можно и без него, конечно.
Суть в том что его нужно останавливать внутри App::replyError() , так как он продолжает работать и блокирует завершение программы.
смотря, какая цель. если программу запутать и потом жаловаться, что «кляты кутешники», то лучше оставить так 🙂
но зачем в синхронном?
Так я и не жаловался. Делаю первые пробы пера с использованием Qt. Немного запутался, но вы подсказали что не так. Проблему решил.
А в синхронном потому что программе не нужно ничего делать пока выполняется сетевой запрос, просто дождаться его завершения и двигаться дальше. Примерно как curl работает. Можно было бы реализовать что-то вроде машины состояний, но в моем случае это лишняя сущность.
Если бы это приложение имело какой-либо интерфейс, например Gui, тогда да, блокировать не стоило бы. В любом случае я очень благодарен за помощь.
Вот блин, говорила мне мама смотри весь код до конца. Но смысл иметь два цикла обработки событий в негуи приложении ускользает от меня.
Верно, в Gui приложении такое делать (и блокировать интерфейс пользователя) совсем недопустимо.
Не, просто QApplication::exec уже создаёт QEventLoop общий на всё приложение. В Gui приложении ты бы разделял i/o события с событиями своей логики в этом цикле, но в данном случае смысла создавать ещё один цикл нет, ну или я не понял задумку. Этот как io_service создавать в тех точках, где ты его создаёшь.
Т.е. достаточно просто сделать вот так:
А все упоминания eventloop просто удалить.
Задумка в том что приложение должно дождаться сигнала QNetworkRequest::finished , а в это время просто ждать, причем не выходя из функции в которой делался этот запрос.
Незнаю как еще объяснить. Некий логический аналог while(1); .
Есть синхронные сетевые запросы, которые блокируют программу до завершения, а есть асинхронные, когда работа программы продолжается до наступления события завершения сетевого запроса.
Таким образом работа приложения завершится после завершения сетевого запроса, и все приложение будет бесполезно.
Весьма странно завершать приложение так. Ведь сетевой ответ нужно дальше как-то использовать.
Дык QApplication::exec это уже while(1) .
Ну тогда это будет типа:
А если хочется прямо синхронно синхронно, то QNetworkReply::waitForReadyRead твой друг.
А если хочется прямо синхронно синхронно, то QNetworkReply::waitForReadyRead твой друг.
вот, да. можно перестать натягивать сову и сделать всё в синхронной манере, если уж хочется, без сигналов (и, вероятно, без QCoreApplication — это надо в доках уточнить. Некоторые классы не требуют инстанса приложения и могут работать без него)
В общем надо либо труселя скидывать, либо крестик надевать. Проги коотрые миксуют синхронный и асинхронный подход на одном уровне абстракции выглядят странно и удивляют наблюдателя.
Выкинул все лишнее. QCoreApplication::exit(1) заменил на обычный exit(EXIT_FAILURE)
QNetworkReply::waitForReadyRead это не мой друг, так как совсем не тоже самое что QNetworkReply::finished
Источник
Qt: выход из консольной проги
В общем надо выйти из проги либо по сигналу (term1_handler — обработчик сигнала SIGTERM), либо по ошибке из метода. По сигналу выходит нормально, из метода — никак. В чем причина ?
По сигналу выходит нормально, из метода — никак. В чем причина ?
Попробуй использовать QCoreApplication::quit() вместо QCoreApplication::exit(0).
На этот раз — промах ! ( т.к. if(1) — тож самое.
Не-а, quit == exit(0)
На этот раз — промах ! ( т.к. if(1) — тож самое.
а без if совсем?
Мне кажется, что не успеваю выйти в event loop и QCoreApplication::exit(0) просто не срабатывает.
Конечно же тож самое.
тогда покажите как используете A
aA — это объект (класса A) верхнего уровня в проекте, объявляется в main.
Сам метод aMethod() сейчас состоит из одной строчки QCoreApplication::exit(0), но, вызывается из конструктора, хм, может это влияет ?
Так конструктор у тебя вне Event loop.
Вызывай метод с помощью QTimer::singleShot().
Спасибо. А это решение «костыльное» или в порядке ?
Сам метод aMethod() сейчас состоит из одной строчки QCoreApplication::exit(0), но, вызывается из конструктора, хм, может это влияет ?
ну event loop то Вы пускаете после того как конструктор отработал поэтому выход из него и «не срабатывает» 🙂
а что сделать-то хотите?
1. Выбрасывай исключение в методе, обрабатывай в main.
2. Вызывай метод вручную из main, проверяй результат.
В общем, прога хоть и консольная, но должна работать в event loop и управляться через socket. В конструкторе паршу некий конфиг, так что, если ошибка — выход.
Это нормальное решение, во всяком случае я видел, чтобы подобное делалось где-то в кдеешном приложении. Как вариант, можешь попробовать invokeMethod с Qt::QueuedConnection.
Вообще, если ты говоришь, что должно управляться через сокет, то зачем тебе вызывать метод в конструкторе? В качестве теста?
Ну так выбрасывай исключение, чтобы в event loop не входить когда не надо.
> В качестве теста?
Ну да, при первом старте.
зачем тебе вызывать метод в конструкторе
Например, разобрали конфиг, создали сокеты, прицепили сигналы к слотам, прицепили сокеты к портам, стали слушать. Это всё делается в конструкторе и сбой на люом этапе должен приводить к завершени. программы.
ТСу: вообще можно программу завершать функцией `exit’.
Ну да, так наиболее правильно будет. Просто хотелось сделать, что ли, более «по Qt’ешному» 🙂
> Это всё делается в конструкторе и сбой
Может быть не следует всё это делать в конструкторе?
Создать объект, после вызвать какой-нибудь listen(), который возвращает код ошибки в случае, если таковая произошла.
> можно программу завершать функцией `exit’
Это не принесет Qt’шных сюрпризов?
В общем, прога хоть и консольная, но должна работать в event loop и управляться через socket. В конструкторе паршу некий конфиг, так что, если ошибка — выход.
я бы оставил контруктору конструкторово, то есть конструирование объекта, а инициализацию вынес бы в отдельный метод
Источник
QCoreApplication quit не работает
Я создал консольную программу. Для целей отладки мне нужно, чтобы программа вышла, если некоторые условия не выполняются. Вот пример:
Как я понимаю, вывод после quit() не должен быть напечатан.
Функция main() моей программы выглядит примерно так:
Кто-нибудь может сказать, почему это происходит?
В настоящее время я использую abort() , но я бы предпочел использовать quit() .
1 ответ
Проблема Итак, у меня есть класс CommandRetriever, который содержит некоторые команды и должен выполнять эти команды в разных потоках. class CommandRetriever < public: CommandRetriever();
CommandRetriever(); void addCommand( QString, Command* ); void executeCommands(); private: QMap
quit() заставляет цикл событий возвращаться, когда он в следующий раз получает управление . Он не вернется немедленно. Так что вам понадобится что-то вроде
или, возможно, что-то более сложное, если вы используете метод, который не вызывается непосредственно из Qt.
В документации по соответствующему методу exit() говорится:
Обратите внимание, что в отличие от функции библиотеки C с тем же именем, эта функция действительно возвращается вызывающему-это обработка событий, которая останавливается.
Похожие вопросы:
Когда я создавал новое мобильное приложение в Qt Creator, я заметил , что в автогенерированном коде они используют #include вместо #include .
Я пытаюсь найти лучшее понимание сигналов Qt и слотов в сочетании с потоками. Поэтому я попробовал это минимальное приложение: foo.h: #include class A : public QObject < Q_OBJECT.
Я пытаюсь использовать Qt в качестве библиотеки (аналогично этой ), потому что я хочу повторно использовать классы Qt в некоторых в настоящее время не Qt приложениях и в общих библиотеках в качестве.
Проблема Итак, у меня есть класс CommandRetriever, который содержит некоторые команды и должен выполнять эти команды в разных потоках. class CommandRetriever < public: CommandRetriever();.
Это было не сразу ясно мне из документов для QCoreApplication::quit () . Отменяются ли какие-либо отложенные события в цикле событий при вызове слота quit()?
Когда сигнал QCoreApplication::quit () срабатывает синхронно перед запуском цикла событий, сигнал игнорируется, и приложение зависает навсегда. Однако при срабатывании с QTimer приложение завершает.
У меня есть приложение, производное от класса QCoreApplication и имеющее дочерний член потока. Когда я удаляю объект приложения, он иногда удаляет его, а иногда нет. class My_class :public.
Я пытаюсь создать клиент для веб-сервиса. Моя цель- посылать запрос на мой сервер каждую секунду . Я использовал эту библиотеку, чтобы помочь мне: QHttp Я создаю таймер, который связываю сигналом с.
Этот простой код аварийно завершает работу в конце программы (Qt 5.9.1, gcc 5.4.1): #include #include std::shared_ptr manager; int.
У меня есть потребность (например, при создании библиотеки) создать экземпляр QCoreApplication в куче, и я обнаружил следующее странное поведение (Qt 5.7): #include #include.
Источник
Корректное завершение QCoreApplication
OC: Windows 7 Professional
Qt: 5.7.0
Есть приложение QCoreApplication:
, которое запускается через QProcess *process . process ->start(. )
Далее выполняется следующий код:
Это означает, что QCoreApplication не ловит эвент MW_CLOSE.
Вопрос: как возможно подключить обработку этого эвента? Или каким еще образом можно остановить QCoreApplication, чтобы код возврата был NormalExit,а не CrashExit?
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Корректное завершение
Когда закрываю окно QGraphicsView`а, процесс остается еще запущен и пишет еще что возникла ошибка.
Корректное завершение работы консольного приложения
Есть консольное приложение на Qt, которое запускает несколько потоков. Фактически в main я создаю.
Наследование QCoreApplication
Нормальная ли практика наследоваться от QCoreApplication? Сейчас пишу класс, который как бы.
QProcess не читает из QCoreApplication + printf
есть приложение app1, которое я запускаю в QProcess: #include int main(int.
Kills the current process, causing it to exit immediately.
On Windows, kill() uses TerminateProcess, and on Unix and OS X, the SIGKILL signal is sent to the process.
Attempts to terminate the process.
The process may not exit as a result of calling this function (it is given the chance to prompt the user for any unsaved files, etc).
On Windows, terminate() posts a WM_CLOSE message to all toplevel windows of the process and then to the main thread of the process itself. On Unix and OS X the SIGTERM signal is sent.
Console applications on Windows that do not run an event loop, or whose event loop does not handle the WM_CLOSE message, can only be terminated by calling kill().
Я уже это читал, и потому спросил как организовать в QCoreApplication обработку эвента WM_CLOSE?
Насколько я понимаю, terminate() отправляет WM_CLOSE в QCoreApplication, но оно не обрабатывает его, продолжает «крутиться» в exec, а потом срабатывает waitForFinished-таймер и код идет на kill()-вызов, который и выдает не NormalExit завершение
Источник