Не получается нагуглить что нибудь хорошего...

В QT можно создавать GUI и управлять им только из основного потока.
MFC тоже что-то подобное хочет.

Это ограничения операционки? Или библиотек?

Дайте пожалуйста ссылку на статью, книгу и т.п. с ответом на вопрос:
-можно ли создавать GUI не в основном потоке?
И с пояснениями.
Если можно, то как.
Если нельзя, то почему.

Заранее благодарен, Сергей.

P_Y>В QT можно создавать GUI и управлять им только из основного потока.

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

Здравствуйте, P_YegreS_P, Вы писали:

P_Y>В QT можно создавать GUI и управлять им только из основного потока.

P_Y>MFC тоже что-то подобное хочет.
В MFC можно создавать многопоточные GUI (потрахаться, конечно, придётся).

P_Y>Это ограничения операционки? Или библиотек?

Отчасти, это ограничения здравого смысла.

Многопоточный GUI хорошо работает, только когда разным потокам принадлежат разные главные окна. Тогда это получается, будто не многопоточное, а многопроцессное приложение.
Если же отдельные контролы живут в другом потоке, то начинаются проблемы синхронизации — вплоть до дедлоков.

Самый распространённый сценарий дедлока.
Окно1 и окно3 в потоке1, окно2 в потоке2.
Окно1 посылает синхронное сообщение (SendMessage) окну2... и ждёт, когда поток2 диспетчеризует это сообщение.
Окно2 получает это сообщение и посылает синхронное сообщение окну3... и, естественно, ждёт, когда поток1 диспетчеризует.
А поток1 всё ещё ждёт, когда поток2 выйдет из диспетчеризации и отправит результат (LRESULT) назад.

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