LINUX.ORG.RU

Qt - как не повесить гуй «тяжелым» методом?

 , , ,


0

1

Я не программист, просто эникей.

Есть формочка в которой производятся манипуляции с базами - создание, удаление, импорт, экспорт. С созданием и удалением все просто - операции быстрые и формочка не зависает и даже при создании базы прекрасно отображается процесс в прогресс баре, да и код собственного говоря помещен в саму формочку из-за его малого объема.

Но дальше я начал заниматься реализаций импорта данных базы из файла. Так как код обещал быть достаточно больших размеров(куча проверок и прочей лабуды) я решил вынести всё это в отдельный объект который по нажатию на кнопочку будет создаваться и отрабатывать.

Суть работы объекта на пальцах:
-Задаем путь до файлов
-Чистим базу
-По порядку передаем файлы на обработку
---Обработка
----цикл Пока не конец файла
-----Читаем строку
-----Записываем в базу строку
----конец цикла
---Конец обработки

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

Как сделать так что бы формочка не умирала на время выполнения импорта? Вынести в отдельный поток и общаться сигналами-слотами? Если мы получили строку то лучше её сразу в базу кидать или лепить один большой запрос для допустим 100 срок и только потом его отправлять? Хотелось бы что бы это по памяти не вылезло хотя бы за 100 мегобайт. Пока это операция при последовательной отправке строк не вылазит за 50 мегов.

Вынести в отдельный поток и общаться сигналами-слотами?

this

f1u77y ★★★★
()

отдельный объект

Отдельный объект — это не отдельный поток же и не отдельный процесс.

А гуй конечно будет виснуть, ты ж в одном потоке всё пытаешься сделать.

anonymous
()
Ответ на: комментарий от nexus86

Могу посоветовать тебе исправлять ошибки и не допускать в дальнейшем.

ichi404
()

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

Не слушай никого в этом треде. QFuture / QFutureWatcher / QtConcurrent::run твой путь.

UVV ★★★★★
()
Ответ на: комментарий от nexus86

что-то не получалось у меня юзать эту штуку, вечно какие-то ошибки сыпались

Как использовал? Какие ошибки?

KblCb ★★★★★
()
Ответ на: комментарий от Gorthauer

Бредятину откуда ты эту сюда принёс?

UVV ★★★★★
()
Ответ на: комментарий от KblCb

да просто вылетало, что конкретно писало уже не помню. Когда тоже самое переписал на QThread, то все работало нормально

nexus86
()
Ответ на: комментарий от Noob_Linux

Все тлн :) Но если pthreads дергать из кутей - зачем тогда они? :) Помницца на одном проекте разрешили 11-е плюсы... Но немедленно встал во весь рост вопрос - а нахера нам буст?

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)

----цикл Пока не конец файла -----Читаем строку -----Записываем в базу строку ----конец цикла ---Конец обработки

this. Либо не делаешь это отдельным циклом, а цепляешь как «задачу» для цикла, перерисовывающего графику, либо в том же цикле даешь формочке перерисоваться («прокачка событий гуя»), либо выносишь этот цикол в поток/асинхр. таску («футуре»). Можно на самом деле по разному (и вообще не обязательно с потоками).

slackwarrior ★★★★★
()

Вся логика по хорошему должна быть вообще в отделньом от гуя процессе.

invy ★★★★★
()
Ответ на: комментарий от heaven__12

Ну... «Фен шуй» - он же плавающий :) Если есть зодача нагрузить N ведер проца - то потоки ок. Если нет такой зодачи (или нет N ведер) - монопенисуально :)

slackwarrior ★★★★★
()

Вынеси рабочие операции в отдельные консольные приложения. В гуе чисто формочки и код для передачи команд. Можно будет проверять и записывать прогресс по аутпуту. Но я не программист. Меня можно игнорировать.

Sakka
()
Ответ на: комментарий от slackwarrior

Спасибо, заюзал, вполне удобная вещь.

Noob_Linux ★★★★
() автор топика
Ответ на: комментарий от heaven__12

Сделают нормально в одном потоке - не получат :) Получат, которые не знают как или сделают криво :)

slackwarrior ★★★★★
()
Ответ на: комментарий от UVV

Нафига ты Qt тогда используешь? Всего лишь высокоуровневое API над X11/WinAPI/etc.

Я не пойму смысла вопроса, ты предлагаешь ТС-у писать linux-only?

gavlig ★★★
()
Ответ на: комментарий от UVV

Забей, я перечитал тред и все мои вопросы отпали.

gavlig ★★★
()
Ответ на: комментарий от gavlig

Я не пойму аргументацию ТС, почему не стоит использовать QtConcurrent. Если ТС не хочет воспользоваться RAII, где есть бесплатная возможность - флаг в руки, транспарант на шею.

UVV ★★★★★
()
Ответ на: комментарий от UVV

Изначально мне показалось что QtConcurrent не целесообразно использовать в моём проекте и что это весьма жирное решение, но почитав документацию сомнения отпали.

Noob_Linux ★★★★
() автор топика
Ответ на: комментарий от UVV

Будет опровержение тезиса, что Qt - высокоуровневое API? Я слушаю.

API - это программный интерфейс. Как правило, говорят над чем-то. Например над системными вызовами, над собственной узконаправленной библиотекой классов. Говоря про Qt, как про «высокоуровневое API», искусственно занижается уровень абстракции идентификации Qt, как функциональной сущности. Qt - это фрэймворк. И отличие его от «высокоурового API» состоит в том, что, помимо описания интерфейса, во фреймворке (как правило) присутствуют дополнительные средства, инструментарий. Можно привести как пример - MOC. Именно он обрабатывает исходный код программиста, строит необходимый каркас С++ кода, и только потом запускает процесс компиляции и линковки.

Таким образом, называя Qt - «высокоуровневым API», формальной ошибки нет. Но, по-факту, ошибка присутствует. Так как мы указываем только на отдельную часть функционала, упуская всю полноту средств.

Аналогия. Сказав «небо цветное», мы тоже не ошибаемся. Формально. Но, указав явный цвет неба, предоставляем более полную достоверную информацию.

Majestio
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.