OberonCore

Это я что-то неправильно делаю, но что именно, понять не могу.

Суть вот в чём.

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

И вся эта музыка вполне себе работает. Только иногда выскакивает вот это:



Куда копать, что бы это значило? Отложенное действие (даже с задержкой в одну секунду) не помогает - всё равно этот же трап, ведущий в

-- Подобная интересная гадость с фреймами была когда-то в Lab-е, где рабочие области в текст вставлялись... Проявлялось нерегулярно. Разобраться руки не дошли, а потом Лаб был закрыт.

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

Илья, спасибо за ответ!

Выкладываю исходники модуля SternResize (вместе с сопутствующими). Смотрите в процедуре


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

Вообще-то Views.HostOf явно помечена в документации как не предназначенная для прикладного программиста.
Это игры с огнём, и результат вполне закономерен.

Если это попытка выйти за ограничения Form, то надо поискать регулярный способ.

Да, конечно, я знаю, что Views.HostOf для внутреннего употребления.

Для чего мне это понадобилось?

Есть надобность подгонять размеры внедрённых отображений под размер формы. Размер формы меняется пользователем (тема viewtopic.php?f=24&t=2622&p=47045#p47045 сюда же).

Задача, на первый взгляд, вроде бы простая: - как только форма изменила свой размер, тут же пропорционально изменить размеры всех внедрённых отображений.

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

Кроме этого, возможность вложенности внедрённых форм требует контроля за каждой формой по отдельности, а не за всем документом в целом.

Поэтому напрашивается такое решение: внедрить особый элемент прямо на форму, которую надо контролировать. Это как бы очевидно, и интерфейс получается интуитивно понятный.

Но как этому элементу следить за размерами своего хоста-формы? Легально - никак. Идеология контейнеров не предполагает подобной активности от внедрённых отображений (регулирование только на уровне предпочтений, а это значит, что нужна обработка сообщений на уровне каждого контрола, что влечёт за собой кучу дополнительных костылей в виде обёрток отображений).

Тут-то Views.HostOf и помогает. Размеры-то определяются правильно, а вот попытка вручную модифицировать размеры внедрённых на форму отображений иногда приводит к трапу.

Сделал немного по-другому.

При изменении размера окна, в окно посылается модельное сообщение:


Отображение получает это сообщение и создаёт отложенное действие (поставил задержку в 1 секунду):


Когда действие срабатывает, то отображение проверяет изменения размеров и ресайзит контролы. Трап всё равно выскакивает (Опять же, не всегда и не везде).

Опытным путём поймал место трапа.

Трап проявляется именно на этой форме.

Всё дело в кнопке Закрыть, которая располагается под блоком закладок TabViews. Так вот, при изменении размера формы по вертикали, закладки в момент ресайза наползают на эту самую кнопку Закрыть (или наоборот) и тут же вылетает трап. После трапа, ресайз заканчивает обработку и наползание отсутствует.

Кнопка самая что ни на есть стандартная! Если её сдвинуть в сторону от закладок, то наползания нет и трапа нет.

Самое интересное, что я стёр эту кнопку, потом разместил новую (привязал процедуры со старой), и трап пропал!

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

Тема важная, все понять не успел, но вот это:
-- мне кажется, неверное утверждение.
Своя вьюха над стандартной формой, вьюха помнит о вложенных кнопках -- и они про нее могут знать, эта вьюха, по сути, отвечает на их запросы,
а все сигналы к форме форвардуются настоящей форме, которая ничего не подозревает.
Нельзя ли как-то так? Любопытно.

Подразумевается замена всей подсистемы Form? Похоже, тут тоже неверное неявное предположение, что это неизбежно.

Но да, корень проблемы тут в том, что в Form не предусмотрены подобные взаимодействия. Мне любопытно, можно ли обойти эти ограничения уже заложенными в ББ "композиционными" средствами.

Я с этого и начинал. Сделал обёртку формы. Но форму обернуть невозможно без потери связи с каркасом (контейнер плотно "впаян" в механизмы ББ). Контролы оборачивать тоже нельзя, потеряется управляемость.


Это предлагал и Е.Темиргалеев, кстати: viewtopic.php?p=47018#p47018, и я даже чуть не встал на этот путь.

Есть уверенность, что это неверно. То есть, что можно все связи сохранить.

Хотя такая полноценная обертка будет громоздкой (не ощущаю, насколько именно).

К примеру, я сделал обёртку типа Views.View для формы, обернул ею стандартную FormViews.View, сохранил в документ и теперь хочу открыть моё отображение в режиме маски: StdCmds.OpenAuxDialog. А получится фигвам, потому что стандартная установка режима маски выглядит так:



Опции контроллера срабатывают только для Containers.View. Таким образом, моя обёртка сработала как экран и я теперь не могу пользоваться стандартной поддержкой каркаса. Значит, мне надо делать обёртку-контейнер. Ради отлова одного-единственного сообщения как-то не хочется

То есть надо что-то генерализовать, выходит.

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

Еще: почему бы просто не сделать свою процедуру открытия в режиме маски?

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


Уже есть такая. Скопипастили к себе HostCmds, HostWindows и StdCmds, чтобы создавать окна с некоторой дополнительной функциональностью.

Дык... Он и есть отдельный - контроллер! Можно вклинить свой контроллер, а внутри пусть он что надо переадресует к стандартному.

Можно перед открытием конкретной формы подменить FormControllers.dir - и вуаля, форма откроется с Вашим контроллером (который внутри себя создаст стандартный).

Ну да, FormControllers.Controller как раз абстрактный, плюс сам по себе небольшой. Единственное, что смущает - обработчики сообщений у него финальные.

Почему финальные? EXTENSIBLE, вроде как.

Что же, всё-таки нашелся способ?

Промблемка интересная, надо бы понять.

А, точно, это я не туда второпях глянул, на обработчики контейнерного View, а вот у контейнерного контроллера обработчики расширяемые, то что надо.

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

Продолжая эксперименты, отчётливо увидел, что трап возникает как раз в момент наползания одного контрола на другой. Уже увеличенный контрол (Field) наползает на другой (TabViews), ещё старого размера.

Если вьюхи пересортировать, то порядок обхода будет другой, наползания не будет и трапа тоже.

Стало быть, ББ в момент моего ресайза начинает обновлять вьюхи. Как-то это надо блокировать, что ли...

Нет! В этом вся и фишка - при загрузке Stores директории не используются - вызывается напрямую Kernel.NewRec с указанным финальным типом! То есть ExternalizeAs имеется, а вот обратно - звиняйте.