> -- Илья Ермаков писал(а):
> Суть проблемы проста.Схематически:Главный цикл обработки сообщений HostMenus.Loop:Таким образом, по WM_TIMER все это хозяйство постоянно крутится.Проблема, однако, в том, что при входе в меню или перетаскивании окна по какому-то сообщению DispatchMessage забирает управление и не возвращает его до выхода из меню / отпускания окна.Сообщения на окна среды продолжают приходить - ОС вызывает обработчики окон напрямую, минуя главный цикл сообщений.В результате чего и actions, и отложенная перерисовка замирают (хотя перерисовка по WM_PAINT, если закрыть выпадающим меню какое-то из отображений, спровоцировав восстановление куска окна, остается).Принудительное обновление можно вызвать через Windows.dir.Update(NIL), но это не выход - ведь с главным потоком перед этим надо синхронизироваться, а как - если цикл сообщений не крутится?Чтобы все работало, нужно выносить эту логику на уровень обработчиков окон, но это решение мне не нравится - не понятно, в какой обработчик это вынести. Среда может быть запущена в режиме /NOAPPWIN и не иметь главного окна. Может не иметь ни одного диалогового. Можно ввести во все обрабочики и оставить в главном цикле, но придется избегать двойной прокрутки одних и тех же действий...В общем, хорошего решения у меня пока нет.Кто что думает?


Все дело в процедуре USER32.DefMDIChildProcA(wnd, message, wParam, lParam) в (HostWindows .DocWinHandler).
При нажатии на заголовок или на рамку окна не выходит из нее до тех пор пока мышь не отпущена. Поэтому отрисовка замирает.
В Delphi такого не наблюдается, хотя там синхронизация реализована через сообщения. Попробую покопать исходники VCL и посмотреть как они обошли проблему DefMDIChildProcA.