Окно, конечно, будет перерисовываться. Но его будет не закрыть, нажатия на кнопки не будут работать. Плохая затея.
В данном случае ты споришь с очевидным фактом: и окно перерисовывается и кнопки замечательно работают.
Ну так этот трюк - ключевой, чтобы программа могла получать очередь сообщений.
О чём я говорю (говорил) с самого начала. Нууу можно ещё, и ещё раз повторить.
Кстати, не обязательно из таймера запускать цикл, можно PostMessage вызвать на пользовательское сообщение, в котором запускать цикл.
Согласен. В данном случае достаточно любого асинхронного сообщения. В самом же общем случае, развязку лучше делать по таймеру, с гарантированной (читай управляемой) задержкой, гарантирующей полное окончание инициаллизации окна-приёмника.
zubr, тут, конечно, MFC, и поэтому вызов WinAPI не зазорен. Но я придерживаюсь правила, что если используешь оболочку, библиотеку или фреймворк, пиши по правилам и в соответствии с идеологией этой оболочки, библиотеки или фреймворка.
Нууу даже с этой точки зрения, нет никаких противоречий твоим правилам:
PumpMessage объекта CWinThread очень даже MFC.
В частности:
You can call PumpMessage directly to force messages to be processed
С единственной рекомендацией:
Calling PumpMessage directly and overriding its default behavior is recommended for advanced users only.
Ну я думаю на них мы уже тянем.
К тому же обновлять окошко быстрее способности человека увидеть результат смысла нет, а бесконечный цикл загрузит ядро CPU под завязку.
Да, в самом общем случае. Но в данном на этот счёт никаких указаний в задании нет. Может результаты будут фиксироваться высокоскоростной видеокамерой.
А если серьёзно, то если таковые и возникнут, например, считывать или отображать данные в единицу времени, то и они решаются элементарным вызовом Sleep() в цикле, на радость процессору.
