В завершение темы, пожалуй, стоит описать построение дерева фреймов при открытии отображения в документе. Просто чтобы зафиксировать в потоке обсуждения.

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

Теперь переходим в пространство документа. Каркас создаёт документ и инициализирует его модель нашим отображением. После чего заставляет окно ББ обновиться. Что же происходит дальше?

ББ-окно задействует средства системного уровня (модуль Views) для перестроения и обновления дерева фреймов. На этом этапе определяются видимые области, то есть происходит отсечение. Более того, обновление дерева фреймов обрамляется работой с буфером порта - чтобы всю отрисовку в конце работы выплюнуть на экран одним махом и тем самым избежать демонстрации пользователю процесса перерисовки.

Самое интересное, что дерево фреймов обновляется ниспадающим образом при перерисовке отображений. Это означает, что первым у нас перерисовывается отображение документа, а ему и назначается корневой фрейм дерева фреймов. Документ, перерисовывая себя, вставляет наше отображение в свой фрейм, и нашей вьюшке назначается новый фрейм (Вы ведёте счёт? Возникло уже два фрейма в дереве!). Дальше всё зависит от того, как ведёт себя наше отображение. Оно может вставлять в свой фрейм другие отображения и таким образом дерево фреймов будет разрастаться "вниз", при этом оставаясь деревом (связным ациклическим графом).

А поскольку у нас работает отсечение, то фреймы за пределами видимой области не попадут в этот процесс и, соответственно, не встроятся в дерево. Из этого можно сделать важный вывод насчёт передачи некоторых сообщений. Сообщения Views.CtrlMessage и Views.Message передаются именно по дереву фреймов, а значит, их получат только видимые отображения.

Да, забыл ещё одну штуку. При создании объекта документа инициализируется его домен, и все остальные персистентные объекты нашего документа будут зарегистрированы именно в этом домене. И, стало быть, домен определит границу, по которой можно понять, что будет сохранено в файл.

Итак, у нас есть окно, из которого растут две структуры. Первая, можно назвать её "контейнерная", начинается с объекта документа со вложенными в него другими объектами. А вторая, это дерево фреймов, которые связаны с видимыми объектами из "контейнерной" структуры.

Наверное, будет нелишним обозначить, что раз отображению выделен фрейм (кстати, важный момент - фрейм назначается в процессе обновления дерева фреймов, поэтому отображение не может что-то у себя нарисовать в произвольный момент времени, именно поэтому мы видим метод Restore у вьюшки, в который передаётся фрейм), то оно может воспользоваться его возможностями для рисования. А фрейм-то связан с портом через свой бегунок. И как раз бегунок реализует все платформенные возможности рисования в окне.

Нормальная такая архитектура, я считаю. Достаточно гибкая, чтобы поддержать другие концепции, отличные от документоцентричности.