Многопоточность и GUI
Есть приложение с GUI, которое рисует окна в своём основном потоке. Я подгружаю плагин через DLL и мне тоже необходимо нарисовать окно.
Вопрос: рисовать окно в основном потоке приложения или можно для этого создать свой поток?
Буду рад линкам на статьи по многопоточности и интерфейсам.
не будет реагировать на мышку.
Его можно будет закрыть из программы.
Основной поток получает сообщения от системы, и оборачивает их в эвенты, а созданный вами поток автоматически этого делать не будет.
То есть, врядли есть причина изголяться, подгружать данные можно в паралельном потоке, а вот рисование надо ставить в общую очередь.
Зачем создавать в приложении еще один поток, когда у каждого контрола есть .Invoke(...)
:-)
Затем, что это не .Net FW.
Ну это же самое главное — чтоб твоё окно прорисовывалось ☺
Лично я бы создал в новом потоке. Собственно, у меня уже был положительный опыт, и вполне нормально такое окно работало, так что не надо тут.
Лично я бы создал в новом потоке. Собственно, у меня уже был положительный опыт, и вполне нормально такое окно работало, так что не надо тут.
После того как создал этот топик, нашёл на страницах MSDN информацию о возможности для каждого потока иметь своё окно. Но что-то тут не так всё просто. Есть какие-то подводные камни. Почему у Qt окна можно создавать только в основном потоке? Понятно, что из-за Qapplication, который обрабатывает события, но вот почему они решили сделать именно так?
Кстати, я потом пересоздал проект в Qt и заменил стандартный таймер фреймворковским, но счастье было недолгим. Через пару неудачных запусков понял, что QTimer тоже нуждается в QApplication и обработчике событий, а это значит, что всё равно надо создавать отдельный поток.
Вот видишь, даже Qt тут не смог помочь…
Вот видишь, даже Qt тут не смог помочь…
По-моему, нигде нет такой межпоточной синхронизации, даже в .NET, чтобы можно было парой строчек кода создать поток, окно и синхронизировать окна разных потоков, заодно где-нибудь влепить таймер, но в нём её реализация мне нравится больше всего. Только переносить плагин на .NET — выше моих сил. В Qt мне хотя бы не пришлось выбрасывать и переписывать все win api вызовы.