Как "усыпить" текущий поток?

[spectre71]

а усыпление поток не заблокирует, ага?

Это семантика.
Блокировка и усыпление неравнозначны, поэтому лучше использовать правильный термин.
Блокировка не всегда усыпляет поток!!! И блокировка имеет смысл при многопоточности.

sleep в основном потоке может быть полезен *исключительно* в однопоточном приложении; для всех остальных случаев есть таймер и система событий.

Не согласен.
Во-первых может сделано быть проще без таймера, как в (1) примере.
Во-вторых есть большая разница между отработкой по таймеру и через sleep. В первом случаее мы входим в цикл обработки сообщений, во втором нет. Собственно (2) пример на этом основан, блокирую интерфейс(в некоторых критических ситуациях) до того как получу(или не получу) доступ к ресурсу.

[denka]

А помоему проще да и правильней было бы вызывать processEvents для блокировки интерфейса

[spectre71]

А помоему проще да и правильней было бы вызывать processEvents для блокировки интерфейса

Наоборот, вызывать processEvents если не хочешь блокировать интерфейс или определенные события!

[ритт]

первый пример, пришедший в голову - даблклик, посреди которого вклинивается sleep

блокировать поток дабы мессаги "не мелькали" ))
даже спорить лениво
не согласен - и не надо

[denka]

А помоему проще да и правильней было бы вызывать processEvents для блокировки интерфейса

Наоборот, вызывать processEvents если не хочешь блокировать интерфейс или определенные события!

Особенно он не блокируются с флагом QEventLoop::ExcludeUserInputEvents

[spectre71]

блокировать поток дабы мессаги "не мелькали" ))
даже спорить лениво
не согласен - и не надо

Да и не надо спорить, можешь предложить простой вариант для следующей задачи:
 - Длительная загрузка данных с индикацией процесса загрузки
 - Каждый этап отображается в splash окне типа "Qt::ToolTip"
 - Должны быть отображены все сообщения, ни одно не должно быть потеряно! При этом чтобы для коротких этапов сообщения не
мелькали, а оставались не менее, допустим 200 ms
 - Индикацией процесса загрузки должна пропасть в момент окончания загрузки.
Пример:

Код

C++ (Qt)
void load (void) {
  SpalashInfo->show();
  SpalashInfo->info("Start Loading"); //200ms
  SpalashInfo->info("do1");  //1000ms
  do1() // 1000ms
  SpalashInfo->info("do2"); //200ms
  do2() // 10ms
  SpalashInfo->info("do3"); //200ms
  do3() // 50ms
  SpalashInfo->info("do4"); //500ms
  do4() // 500ms
  ...
  SpalashInfo->info("done"); // 200ms
  SpalashInfo->hide();
}
 

 

[spectre71]

Особенно он не блокируются с флагом QEventLoop::ExcludeUserInputEvents

если не хочешь блокировать интерфейс или определенные события!
через processEvents ты не блокируешь, а наоборот.

[ритт]

могу, конечно ))
если это *важные* мессаги, выбрать для их отображения более потребное место, чем сплэш; если это мега-важные мессаги, показывать их через очередь QMessageBox'ов; если это мессаги не более важные, чем "запускается это", "читается то", показывать их на сплэше без всяких велосипедов.

[pastor]

> Длительная загрузка данных с индикацией процесса загрузки

Длительную загрузка данных можно (нужно) вынести в отдельный поток. Тогда не прийдется "трогать" гуевый поток

[BRE]

- Должны быть отображены все сообщения, ни одно не должно быть потеряно! При этом чтобы для коротких этапов сообщения не
мелькали, а оставались не менее, допустим 200 ms

Вот лично я, как пользователь, был бы против затормаживания программы ради возможности прочесть сообщение. Да и сообщения я буду читать максимум один раз (во время первого запуска), потом в это время буду заниматься более интересными делами.

[pastor]

если это *важные* мессаги, выбрать для их отображения более потребное место, чем сплэш; если это мега-важные мессаги, показывать их через очередь QMessageBox'ов; если это мессаги не более важные, чем "запускается это", "читается то", показывать их на сплэше без всяких велосипедов.

+1

[spectre71]

могу, конечно ))
если это *важные* мессаги, выбрать для их отображения более потребное место, чем сплэш; если это мега-важные мессаги, показывать их через очередь QMessageBox'ов; если это мессаги не более важные, чем "запускается это", "читается то", показывать их на сплэше без всяких велосипедов.

Это статус загрузки, а не Мессаги.
И задача именно в показе всех (определенных) этапов. И если что-то выводиться, оно должно оставаться на определенный(не меньше некоторого заданного) промежуток времени, иначе смотриться плохо когда сообщения мелькают.
Я привел простой вариант, который реализован у меня. Естественно что минимальный промежуток должен быть достаточн мал (~50-200ms).

[spectre71]

Длительную загрузка данных можно (нужно) вынести в отдельный поток. Тогда не прийдется "трогать" гуевый поток

В моем случае это не простое решение! Потребуется сложная синхронизация!

[pastor]

В моем случае это не простое решение! Потребуется сложная синхронизация!

Синхронизация чего с чем? Пусть данные грузятся в отдельном потоке, и,  когда это нужно, он будет подавать статус сообщения в главный поток. Там ты их ловишь и показываешь где нужно.

Немного не пойму вот этого:

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

Если все дело в красоте, то это глупо тормозить процесс загрузки при больших объемах данных. Пусть будет 100 мелких сообщений умножаем на 200мс и уже получаем 20 сек выкинутые в воздух. Кому это нужно?

[spectre71]

Вот лично я, как пользователь, был бы против затормаживания программы ради возможности прочесть сообщение. Да и сообщения я буду читать максимум один раз (во время первого запуска), потом в это время буду заниматься более интересными делами.

Это статус загрузки, нужен для того чтобы во время длительных действий было понятно что приложение не висит, а что-то делает.
Или запустилось и загружает данные итд...
А дополнительное замараживание(при необходимости) между выводами разных сообщений в окне статуса достаточно маленькое, чтобы не была заметна заморозка, но при этом достаточное чтобы сообщения не мелькали(что может раздражать пользователя)