Суть проблемы проста.

Схематически:

Главный цикл обработки сообщений HostMenus.Loop:
## Код:
```
WHILE WinApi.GetMessage DO
  ...
  Services.actionHook.Loop; - вот здесь идет выполнение всех поставленных в очередь Services действий.
  ...
  INC(n);
  IF n > num THEN
      Windows.dir.Update(NIL); n := 0
  END;
  - а вот здесь та самая отложенная перерисовка окошек. Параметр num задает, как часто она делается. По умолчанию num = 10.
  DispatchMessage(...)
END
```

Таким образом, по WM_TIMER все это хозяйство постоянно крутится.
Проблема, однако, в том, что при входе в меню или перетаскивании окна по какому-то сообщению DispatchMessage забирает управление и не возвращает его до выхода из меню / отпускания окна.
Сообщения на окна среды продолжают приходить - ОС вызывает обработчики окон напрямую, минуя главный цикл сообщений.
В результате чего и actions, и отложенная перерисовка замирают (хотя перерисовка по WM_PAINT, если закрыть выпадающим меню какое-то из отображений, спровоцировав восстановление куска окна, остается).

Принудительное обновление можно вызвать через Windows.dir.Update(NIL), но это не выход - ведь с главным потоком перед этим надо синхронизироваться, а как - если цикл сообщений не крутится?

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

В общем, хорошего решения у меня пока нет.

Кто что думает?