OberonCore

Проблемка такая:

определяется вьюшка так, чтобы растягиваться по окну (horFitToWin := TRUE ...).
при каждой отрисовке запоминает в своих полях свой текущий размер (берет через v.context.GetSize).
на SizePref отвечает этим размером.
при сохранении на диск сохраняет этот размер, а при считывании -- восстанавливает значения.

Теперь:
создаем такую вьюшку, задавая ей размер некий размер по умолчанию (SIC: этот размер и будет проблемой),
и открываем в отдельном окошке.
растягиваем мышкой окно. вьюшка адаптируется как приказано.
сохраняем вьюшку (File, Save), закрываем.

Открываем снова -- и видим странное дело (отслеживая в Log сообщения):
сначала ББ просит SizePref, вьюшка отвечает правильными -- считанными с диска размерами (это дважды).
Но затем идет вызов Restore, и ББ дает контекст, в котором размеры вьюшки -- те самые изначальные, до всяких растягиваний окна.

Нетрудно понять, что ББ не может заглянуть внутрь модуля и отгадать, где там хранятся эти изначальные размеры -- но можно и доказать, что они считываются с диска:
достаточно после сохранения и закрытия вьюшки изменить эти начальные размеры в определяющем вьюшку модуле, скомпилировать его, перегрузить для надежности весь ББ, и открыть вьюшку.

То есть: система (ББ+виндуса) помнит и хранит для вьюшки самый ее первый размер.
И при записи (обычные системные команды) записывает его.
А при открывании вьюшки -- откуда-то выцарапывает их и пытается навязать их опять.

Как обойти эту хрень я знаю. Даже два способа, причем даже и не сложно.

Но если кто-то может мне объяснить эту, повторю, хрень -- в каких дебрях застревают самые первоначальные размеры и кто их вытаскивает на свет божий, то заранее спасибо.

Возможно, что View получает размеры по умолчанию при иницализации модуля.

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

То есть Вы хотите сказать, что когда я мышкой поресайзил окно, то документ этого не заметил?
То есть на диск сохранил нересайзенные значения?
Тогда я склонен считать это багом.

Но надо посмотреть, спасибо за направление.

Невозможность этого была доказана.

Я уже жаловался, что работа с документами абсолютно недокументирована.


Конечно. Окно же может быть не единственным.

Открываем окно. Выполняем "Tools"/ "Document Size...". Устанавливаем размеры документа "Fixed". Нажимаем ctrl+spase. Ресайзим окно мышкой и наблюдаем, что размеры документа не меняются. Но их можно изменить, подвигав темные квадратики. При сохранении документа именно эти размеры и запишутся.
Теперь установим размеры документа "Window Width"x "Window Heigh". Повторяем эксперимент с мышкой. Видим, как документ подгоняется под окно, а квадратики стали белыми. Но теперь размеры документа не сохраняются.

Не аргумент: есть главное окно, оно единственное.

А ещё есть принтеры.

Как это? Главный - документ, а все его окна - просто отображения, вполне между собой равные. Тот факт, что одно из них было открыто раньше - просто случайность. Или у моделей есть "главная" вьюшка и второстепенные?

PS. Это я к тому, что в общем случае документ не может ориентироваться на параметры какого либо конкретного окна, даже если это окно одно. Получится неоправданное усложнение

С принтерами как раз проблемы нет:

Ports.IsPrinterPort (p: Port): BOOLEAN;

Вы (или авторы ББ ) немножко запутали.

Мне нужна простая как репа вещь: у вьюшки есть одно -- одно! см. документацию ББ -- главное окно, и она хочет определить размер этого окна. Что она с ним будет делать -- ее (моё) дело.
В данном случае я хочу потом открыть ее снова точно в той же позиции (я взял код из Desktop, но там всё сложно и низкоуровнево).

Повторю: понятие главного окна -- концептуальное в ББ. И оно никак не отражено в API.

Плюс ко всему: речь о вьюшке без модели.
Тут и вторичные окна не открываются.
Так что вообще проблемы с множественностью окон нет.

Вьюшка без модели -- одно окно, нужно сохранять ее размер.

Это недодумка в ББ.

Это всё понятно. Но! Понятие "окно" в ББ ниразу не концептуальное. Концептуальное - документ, и, соответственно, документоориентированный интерфейс. Отсюда и отсутствие нормальных "окон" в API.


Если вьюшка не имеет модели - это не значит что модели нет вообще. Модель есть у документа, и окно суть - отображение документа.

Проблема в том, что ББ вынужден работать в абсолютно неродной для себя среде

PS. Посмотрел в документации. Действительно, там есть понятие "основное окно документа". В одном абзаце упоминается. Но оно введено исключительно как соглашение, для какого-то (сиюминутного) удобства разработчиков. Концепции основного окна нет!

У вьюшки нет ни одного окна.

Есть. Откройте любой текст и нажмите F2.

И что? Это показывает лишь то, что окна имеются в нижележащей ОС. А в ББ концепции окон нет! Равно как и меню, и горячих клавиш. Всё это зарыто в подсистеме Host или во вспомогательных (а потому недокументированных) модулях. Это конечно плохо, но так уж сложилось

Уф.

Да мне нужна не философия, а простая вещь!

Вьюшка без модели. Второе окно у нее не открывается хоть тресни. Одно оно! Оно же и размер документа. Я с ним работаю (графики там поудобней растягиваю-сдвигаю то-да-сё), устрою поудобней -- и хочу в таком виде чтобы и назавтра оно было, и на послезавтра.

На кой ляд мне сохранять какой-то случайный дефолтный начальный размер и потом всегда его восстанавливать?

Вот и вся концепция

Вы же не требуете наличия составных документов от IDE Delphi. Нету - значит нету. Нужно делать самому. Либо частное сиюминутное решение, либо общее. Только и всего.

А правы оба на самом деле.

Только с точки зрения ББ последняя, верхняя абстракция до ОС - фрейм. Окон действительно нет.
И Трурль прав. У отображения окна нет. Его (отображение) можно показать через фрейм.
И самое смешное, второй фрейм (под второе окно) не сделаешь, т.к. модели нет, к которой можно второе отображение подключить.
Забавно.

P.S. Вот она, кстати, трурлевская гуюшка! Вьюшка без модели!
P.P.S. А ведь технически, ничего не нарушая (не нарушая фреймворка), можно спокойно модернизировать связку ББ - ОС...хм...

Уточню: под второе окно делается не просто фрейм, а копия вьюшки. Два фрейма на одну вьюшку - это ситуация с вложенными отображениями, если родительское открыто в двух окнах.