OberonCore

Всем привет.
Объясните кто-нибудь как перерисовываются стандартные контролы.
Что происходит когда среда вызывает следующее:
PROCEDURE (c: VectorField) Restore (f: Views.Frame; l, t, r, b: INTEGER);
BEGIN
WITH f: StdCFrames.Frame DO f.Restore(l, t, r, b) END
END Restore;

Views.Frame.Restore вообще абстракт.
Как это работает?
Я так понимаю что это WinAPI. Так где-ж этот API вызывается то?

У Вас же сказано:

Соответственно f здесь уже имеет тип StdCFrames.Frame (смотрите определение оператора WITH), и вызывается StdCFrames.Frame.Restore.
Собственно говоря StdCFrames.Frame тоже абстрактный тип, но если посмотреть внимательно, можно увидеть в модуле StdCFrames вот такие строчки:

Значит где-то должен быть модуль, предоставляющий фабрику и реализующий все контролы. Такой модуль есть - это HostCFrames (из подсистемы Host, что логично). Вот там всё WinApi и спрятано. То есть в указанном примере вызывается на самом деле HostCFrames.VectorField.Restore (правда нет такого стандартного контрола - VectorField)

Как знакомо

Вам знакомо, а я башку сломал, пока до меня дошло, где же, собственно, работающий код-то располагается. И почему он называется Restore, а не Paint. И еще много других почему. Я только вот вопросы на форум не задавал, а сам разбирался...

Вот, кстати, для меня в последнее время загадка - почему подобные вещи вызывают затруднения у пришёдших "со стороны"? Ведь абстрактный интерфейс - не тайна за семью печатями, а вполне известный в "майнстриме" паттерн. По идее, ключевое слово ABSTRACT должно сразу наводить на верную мысль, однако же такого не происходит. Почему, вот интересно.

Сразу оговорюсь, что не испытываю ни малейшей капли иронического чувства, тем более - что сам башку ломал тоже

Проблема в том, что реализацию найти - труднее, чем могло бы быть. Это ведь вопрос конвенции, а где её прочитать? На виду должна бы быть.

В общем случае - реализация может быть где угодно. Информацию про особенности реализации можно достать только из пакета самой реализации. И, да, конвенция, но опять же - в самой реализации.

Угу. Вот где лежит умолчальная реализация Views.ViewHook сможете сразу сказать? И почему именно там? Или откуда берётся конвертер на файлы .odc ...

Так и я ровно про это

Только с помощью поиска строчки "Views.SetViewHook" по содержимому файлов А документация к StdDialog выглядит удручающе: "This is a private module of BlackBox. Its existence is necessary for BlackBox to work correctly.".

Но, по-моему, вопрос ведь не про то, что StdDialog не документирован, и не про то, почему Host и почему Std, а про сам паттерн.

Новичкам - простой способ найти реализацию: открыть Info->Global Variables на абстрактный модуль и посмотреть, чьи разъёмы в него воткнуты.

О-о-о, так вот для чего эти Global Variables! ))

Думаю, такой ответ можно поместить в ЧаВо.

Оказывается все просто!

Мдя... Никак не привыкну что в жизни все проще чем кажется.
Посмотрел внимательно на HostCFrames и ...
MODULE HostCFrames;
...
PROCEDURE Install;
VAR dir: Directory;
BEGIN
NEW(dir); StdCFrames.SetDir(dir)
END Install;
...
PROCEDURE Init;
VAR v: INTEGER;
BEGIN
StdCFrames.setFocus := TRUE;
SetDefFonts;
scW := USER32.GetSystemMetrics(0); (* screen width *)
scH := USER32.GetSystemMetrics(1); (* screen height *)
instance := KERNEL32.GetModuleHandleA(NIL);
v := KERNEL32.GetVersion();
osVersion := v MOD 256 * 100 + v DIV 256 MOD 256;
InitClass;
InitNationalInfo;
InitColors;
Install
END Init;

BEGIN
Init
END HostCFrames.


Это каким третьим глазом, я должен был догадаться что реализация существует уже после загрузки BlackBox.
Я ведь сначала искал реализацию и фабрики в том модуле, потом в импортированных. Не нашел, и решил что мистика...
Вообще по хорошему это должно явно делаться по моему.
Прямой: HostCFrames.Init
Или раз уж там инициализация при загрузке: IMPORT HostCFrames;

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

Часто делается так - модуль-интерфейс затягивает реализацию по-умолчанию динамически, через Dialog.Call("Impl.Init") или Kernel.LoadMod.

Но что правда, то правда, в ББ нет места, где внятно был бы задан порядок загрузки и соединения модулей. Всё это втягивается по цепи импорта от HostMenus.

Мне кажется, такое место отсутствует по причине неопределённости. Неизвестно, какая реализация потребуется в данный момент времени. Такая особенность компонентных систем.