Приветствую всех.

Жизнь тут заставила решить полностью проблему того, что в некоторых режимах в ББ блокируются Action-ы и не перерисовываются динамические вьюшки.
Пришлось это решить для задачи, где, во-первых, всегда должна выполняться фоновая логика, во-вторых, недопустимо прерывание интерактивной визуализации.
Просьба проверить, указать на потенциальные косяки. И при желании внедрить в сборки и т.п.

История вопроса:
- в некоторых режимах взаимодействия с пользователем перестают выполняться фоновые Services.Action И\ИЛИ перерисовываться динамические вьюшки (увидеть легко на примере "кубик не крутится, часики не тикают" - для Obx->New Cube и Tools->Insert Clocks).

Обсуждения по этой теме:
viewtopic.php?f=114&t=4287&p=79196&hilit=Ports+Input#p79196
viewtopic.php?f=31&t=367
viewtopic.php?f=24&t=370

Суммирую здесь.
В исходном ББ от Оминк (и в том числе в сборке OberonCore) это происходит в следующих случаях:
1) При выпаденном меню или контекстном меню.
Это исправлялось когда-то после обсуждений на форуме Александром Ильиным в одном из его патчей (http://ajsoft.narod.ru/blackbox/index.htm,http://blackboxcb.livejournal.com/)
Я так понимаю, что в некоторых сборках коллег, в частности, у Ивана Денисова в 1.7, этот патч есть.
Там идёт добавление в процедуру HostWindows.Idle операций Services.actionHook.Step и Windows.dir.Update(NIL) - для перерисовки всех окон. Процедура Idle дёргается операционкой, пока какая-то из функций WinApi работы с меню блокирует выполнение.

2) Если вьюшка хочет последить за мышкой при зажатой клавише, то ББ предлагает блокирующий способ, который и критиковали, и защищали (см. ссылки на обсуждения выше). В HandleCtrlMsg при TrackMsg мы можем сделать цикл и следить за мышью через f.Input.
Разумеется, при этом управление остаётся в этом цикле, пока пользователь не отпустит кнопку мыши.
Исправление вносил Marco Ciot, потом Александр Ильин вводил в своём общем патче "PaintProblem".
Решение, естественно, требует добавления в процедуру HostPorts.Rider.Input вызова Service.actionHook.Step. Вызывать перерисовку экрана оттуда, конечно, нельзя (это высокочастотный цикл опроса мыши).
Решение:
## Код:
```
PROCEDURE (rd: Rider) Input* (OUT x, y: INTEGER; OUT modifiers: SET; OUT isDown: BOOLEAN);
      VAR msg: WinApi.MSG; wnd, mw: WinApi.HANDLE; pt: WinApi.POINT; res: INTEGER; set: SET;
   BEGIN
      Services.actionHook.Step;   (* marco ciot:060325 *)
      (* WinApi.Sleep(1); *) (* ИЕ - Не нужно, раз мы даём работать задачам *)
```

Предыдущие авторы не убирали Sleep(1). Я считаю, что теперь стоит его убрать. Не вносить дополнительных тормозов. Лучше подгрузить процессор на период удержания мыши пользователем, чем внести лишние паузы.

На этом история имеющихся решений заканчивается.
Но не заканчиваются проблемы.

3) Остаются блокировки при удержании мыши зажатой над стандартными контролами (button, только тестьте над активным, с командой, над disabled эффекта нет; в момент протяжки выделения в TextEdit, в момент задержки клика на кнопке SpinEdit).
Блокирующий цикл находится в HostCFrames в процедуре HandleMouse (там второй REPEAT).
Решается всё тем же добавлением туда Services.actionHook.Step.

4) После всего вышеописанного Services.Action не прерываются никогда. Однако "кубик не крутится, часики не тикают" в случаях 2) и 3) (в случае с меню нормально, так как там обновляем все окна).

О решении этой проблемы - в следующем сообщении.