1) Почему после Dialog.Update не вызывается Restore. Скажите, а где вы храните link на интерактор? В view.prop.link или в каком-нибудь самопальном поле? Controls.Control в обработчике HandleViewMsg сранивает параметр id NotifyMsg со своим prop.link, и если они совпадают, делает guard check и Views.Update. Другое поле он, естественно, не может проверить, и потому пропустит NotifyMsg "мимо ушей". Можно, конечно, написать свой HandleViewMsg2 для NotifyMsg, но лучше просто хранить ссылку в предназначенном поле.
2) PollSectionMsg не вызывется, надо думать, по той же причине.
3) Касательно view.context.GetSize - эта процедура возвращает размер отображения. Не размер содержимого отображения, за который отвечаете вы сами, а именно размер, который отображение занимает в контейнере или окне. Последнее слово касательно этого размера принадлежит контейнеру, а не вашему отображению. Ваше отображение может лишь высказать свои пожелания, вызвав context.SetSize. Соответственно, если ваше отображение обернуто в скроллер (StdScrollers), то скроллер при изменении размера автоматически даст сролбары. Удобно то, что для простых отображений вообще не надо обрабатывать ScrollMsg и PollSectionMsg - достаточно просто устанавливать размер отображения равным размеру содержимого. Restore будет перерисовывать отображение целиком, но кадр сам выполнит нужный сдвиг и отсечение. Только для больших отображений, например, текстов или таблиц, делается своя обработка скроллинга. При этом размер отображения по вертикали всегда остается постоянным, мы сами по внутреннему состоянию отображения определяем, какой кусок рисовать в Restore и через PollSectionMsg говорим "крыше", на какой позиции мы находимся. А вот горизонтальный скроллинг для текстов и таблиц обычно вручную не обрабатывается, там просто меняется размер отображения, так проще, т.к. ширина текстов обычно невелика.
Еще нужно написать обработку в HandlePropMsg сообщения SizePref, которое среда посылает отображению при его загрузке или открытии, чтобы запросить желаемый размер - читайте 6 раздел хелпа "Конструирование отображений".
Цитата:
Закрывая доступ к методам, и таким образом, защитившись от "хрупкости" базового класса мы сводим повторное использование кода к очень малым величинам, и переходим к китайскому методу Copy/Paste).
К сожалению, за надежность приходится платить. Как ни парадоксально, позволить бесконтрольно расширять систему - значит вскоре свести ее расширяемость вообще на нет, т.к. разработчик не сможет сделать ни шага в сторону без того, чтобы не вызвать проблемы у множества клиентов.
Кстати, не надо забывать и об агрегации как заменителе наследования. Во многих случаях такое решение не только приемлемо, но и единственно возможно: обернуть объект какого-либо закрытого для наследования типа в свой - потомок от того же абстрактного типа, что и обернутый, и делегировать часть вызовов обернутому объекту. Может быть, это подошло бы и в вашем случае?
А вот Copy-Paste действительно помогает. Если время не терпит, иногда беру исходный код из стандартного модуля и изменяю в нем только то, что нужно. Вообще, открытые коды ББ здорово помогают, без них разобраться и быстро начать работать было бы гораздо сложнее.