Обновление текста метки

[tumanovalex]

Здравствуйте!
Метод:

void MainWindow::Start()
{
  lblInfo->clear();
  lblInfo->setText("");
  QThread::sleep(10);
  QString fileNameSave = lblFileNameResults->text();
  if(fileNameSave.isEmpty())
  {
    GetFileName(true);
  }
  fileNameSave = lblFileNameResults->text();
  lblInfo->setText("Программа завершилась!");
}

Установленный после первого нажатия кнопки Старт текст в метке при следующих нажатиях этой кнопки не обновляется. Помогите, пожалуйста. Проект прикрепил.
Прикреплённый файлqtGuiTest.zip (4,51 Кбайт, скачиваний: 17)

[Majestio]

Все дело в QThread::sleep(10); Это конструкция не только усыпляет поток, но и приостанавливает обработку событий в главном потоке (читай "GUI потоке"), в том числе и обработку событий отрисовки. Лучше использовать обработки в других потоках и связывать эти потоки сигналами. Но если уж хочется сделать в основном потоке - можно использовать неблокирующий события вариант задержки:

QEventLoop Loop;
QTimer Timer;
connect(&Timer, &QTimer::timeout, &Loop, &QEventLoop::quit);
Timer.setSingleShot(true);
Timer.start(1000);
Loop.exec();

Варианты задержек.

[tumanovalex]

Цитата Majestio @ 03.06.25, 06:41

Все дело в QThread::sleep(10)

По-моему, дело не в этом. Я убрал задержку:

void MainWindow::Start()
{
  lblInfo->clear();
  lblInfo->setText("");
  QString fileNameSave = lblFileNameResults->text();
  if(fileNameSave.isEmpty())
  {
    GetFileName(true);
  }
  fileNameSave = lblFileNameResults->text();
  lblInfo->setText("Программа завершилась!");
}

текст все равно не обновляется. Задержку я вводил только потому, чтобы увидеть, как становится пустым текст в метке.

Добавлено 03.06.25, 08:25
Я тормоз. Все обновляется, задержка не нужна.

Сообщение отредактировано: tumanovalex - 03.06.25, 08:25

[Majestio]

Повторюсь - можно и с задержкой, но только по моему варианту. Ну а так, конечно, если задержка не нужна для чего-то другого, то лучше без нее.

[tumanovalex]

Спасибо, понятно.

[Majestio]

Цитата tumanovalex @ 03.06.25, 09:45

Спасибо, понятно.

И на будущее - лови лайфхак ...

Твои программы могут как угодно быстро рассчитывать и обсчитывать твои данные. Но это совсем не значит, что на каждое изменение ты должен перерисовывать значение соответствующего "контрола". Нет, конечно можешь - но будешь просто "сжигать" впустую нагрузку на CPU. Для человеческого восприятия наличия изменений - вполне достаточно не более 4 раз в секунду изменять визуально значение какой-то величины в интерфейсе. И это нужно делать, вернее ограничивать, в обрабатывающем потоке. Т.е. там нужно что-то обрабатывать и слать сигнал основному потоку только тогда, когда предыдущий сигнал был отослан 0.25 сек или более тому назад.

Тогда, и только тогда, твоя прога будет работать по фэн-шую. И с такой прогой можно будет даже спокойно ехать в КНДР, с полной уверенностью, что тебя там за нее не расстреляют!

[tumanovalex]

Цитата Majestio @ 04.06.25, 00:33

Для человеческого восприятия наличия изменений - вполне достаточно не более 4 раз в секунду изменять визуально значение какой-то величины в интерфейсе.

Спасибо, в будущем обязательно буду это учитывать.

[amk]

Когда-то, ещё во времена зелёных текстовых терминалов, подключенных к мэйнфреймам по интерфейсу "токовая петля" со скоростью передачи, не превышающей 2400 бит/с, было произведено исследование, как человек воспринимает время между подачей команды и ответом программы.
Если время было меньше половины секунды, оператор начинал нервничать: он ещё не успел команду подать, а ответ уже на экране. А не выдаёт ли программа какую-нибудь чушь?
Если ничего не присходило больше 5 с, оператор начинал сомневаться, а не зависла ли программа.
Если задержка превышала 15 с, оператор уже не сомневался, а был уверен - программа висит.

Так что, если выполнение действия будет занимать меньше 5 с, можно вообще ничего не выводить на экран до его завершения - пользователь всё равно не успеет обратить внимание. Если больше, достаточно обновлять текстовые сообщения раз в полсекунды-секунду, индикаторы, наверно от 4 до 10 раз в секунду. Чаще обновлять нет смысла.
Следует также избегать медленных прогресс-баров, если на добавление очередного пикселя уходит по полминуты, то такой прогресс-бар показывает только, какая часть уже сделана, но никак не демонстрирует, что процесс ещё движется. В таком случае прогресс-бар имеет смысл сопроводить какой-нибудь инфорнмацией, меняющейся хотя-бы раз в несколько секунд. Оценка оставшегося времени, например. Хотя в Хроме, даже это сделали через одно место. Например, он сообщает до окончания загрузки "осталось 3 часа", и через час меняет сообщение на "осталось 2 часа", причём 2 часа для него это от 2 часов, до почти 3 часов.

[ЫукпШ]

Как-то раз я решил померить, сколько времени требуется
для полной перерисовки экрана 1920x1080, 32 бита.
Компьютер был бюджетный, ~2013 года выпуска.
Потребовалось меньше 1 [мс].

[tumanovalex]

amkЫукпШ Спасибо за пояснения