Dialog.Update - это стандартная процедура, которая используется для обновления всех отображений, связанных с какой-либо записью-интерактором.
Смотрите, что она делает: посылает по всей иерархии отображений сообщение Views.NotifyMsg:
NotifyMsg = EXTENSIBLE RECORD (Views.Message)
view-: Views.View; (* = NIL *)
id0, (* = ADR(интерактора) *) id1: INTEGER;
opts: SET (* = update, GuardChack *)
END
Каждое отображение в своей HandleViewMsg смотрит на адрес интерактора и решает, относится к нему это сообщение или нет. В Controls.Control такой HandleViewMsg уже реализован. Так как при вызове Dialog.Update в opts присутствует update и GuardCheck, то Controls.HandleViewMsg будет проверять охрану и вызывать Views.Update.

Что делает Views.Update? Она ставит прямоугольник отображения в очередь отложенного обновления, которой владеет корневой кадр соответствующего окна. Через некоторое время будет очередное обновление экрана, и будет вызвана Restore вашего отображения.

А вот уже в Restore нужно реагировать на все изменения интерактора: перерисовывать данные, менять свой размер и т.п. В наиболее распостраненном случае достаточно вызвать view.context.SetSize - а скроллинг обеспечит сама среда, в механизме кадров, ну и соотв. полосы прокрутки у обертки StdScrollers тоже появятся автоматически.
Но, как я понимаю, вы переделываете SqlControls, и там размер отображения (по вертикали) не меняется в целях скорости, а сообщения ScrollMsg и PollSectionMsg отрабатываются самостоятельно. Тогда в Restore вам нужно поменять какую-то внутреннюю переменную отображения, которая указывает на число строк или что там... Все остальное касательно прокрутки, как я уже говорил, сделает среда.

Что касается Dialog.Update и Views.Update, то при программировании на уровне "кидания контролов на форму" используется Dialog.Update (обычно ведь view неизвестен, известен только интерактор). Views.Update нужен для перерисовки конкретного известного нам отображения.

Да, по нашим наблюдениям, перерисовка и вызов Restore иногда происходит асинхронно (ядро ББ многопоточное, там от 5 до 8 потоков иногда крутятся параллельно). Поэтому надо руководствоваться следующим правилом: как можно меньше побочных эффектов. Можно менять только состояние своего отображения и вызывать ТОЛЬКО функции с повторной входимостью. Проблема выплыла, когда мы в Restore вызывали функции из внешней DLL без повторной входимости. Долго не могли понять, почему DLL работала неправильно, пока не перенесли все вызовы из Restore в другое место. Только тогда поняли весь смысл фразы из документации: "Разработчик не должен делать никаких предположений относительно момента вызова Restore"...