OberonCore

Создаю диалог. В меню Tools -> Dialog Size высоту и ширину диалога выбираю как Window Height и Window Width соотвественно.
Кладу Edit (многгострочный). Запускаю диалог.
При максимизации (и при изменении размеров) диалога хочу сделать выравнивание окна редактирования по краям диалога.
Смотрел пример для отображений. Вопросов нет. Как быть в случае с диалогом - мне непонятно.

Не понял Вашего вопроса. Можно конкретнее: каким вызовом открываете диалог? OpenAuxDialog и OpenToolDialog не позволяют менять размер диалога. А OpenBrowser открывает не сам по себе диалог, а документ.

Вы, я так понимаю, установили у формы размер "по окну", сохранили документ в Mask Mode и потом открываете вызовом OpenBrowser?

Верно.
Запутался - можно ли создать диалог с изменяемыми формами? Ни ToolDialog, ни AuxDialog - не походят.

Как сказать. В ББ есть два типа окон: окна документов, окна диалогов и вспомогательные окна.
Последние бывают инструментальные (Tool) и вспомогательные (Aux). Они открываются процедурами OpenTool/AuxDialog и в принципе размеры свои менять не могут.
Нечто меняющее размеры может быть открыто либо в окне документа (OpenDoc) - это, можно сказать, редактор для документа, при закрытии его будет спрошено "Хотите ли вы сохранить...", и во вспомогательном окне (OpenBroser, Views.OpenAux(v) и т.п.). Однако и вспомогательное окно может находиться в режиме редактирования, просто при закрытии не будет предложения сохранить.

Так вот, во вспомогательном окне можно открыть любой документ, в том числе и ту же самую форму. И размеры свои она будет менять, как у вас и получилось, собственно. Однако это немного необычный режим. Я, например, предполчитаю тогда уже использовать текстовый документ с вкрапленными контролами, в режиме маски текст от формы ничем не отличается.

Если очень нужно изменить размеры элементов? Надо каким-то образом узнать View нужной формы. Либо вы после OpenBrowser сразу берете v := (FormViews.View)Controllers.FocusView или v := FormViews.Focus(), что эквивалентно. Ну или сначала вообще загрружаете документ v := Views.OldView("имя файла), а потом уже открываете его Views.OpenAux(v).
Потом с помощью reader := v.ThisModel().NewReader() находите интересующий вас контрол controlView (по его label, например). Затем вызываете v.ThisModel().Resize(controlView, left, top, right, bottom).
Размер самой формы можно узнать v.context.GetSize(w, h).

А вот вопрос, как отслеживать изменение размера, остается открытым. Отловить сообщение? Это возможно, но с этим пока я не работал, и сомневаюсь, что кто-то знает готовое решение... В этом направлении надо копать Properties и Controllers.
Подобные задачи в ББ еще решаются с помощью периодических действий, когда раз в какое-то время происходит проверка и изменение. Объявите своего наследника Services.Action с процедурой Do, которая будет изменять размеры контролов и переустанавливать свое событие на следующее время - там в Services это описано.

Сложновато? Надо будет подобные возможности внести в библиотеки.
Вообще говоря, с динамикой интерфейсов в ББ есть определенные сложности. Правда, доработать ее - особых проблем нет. Почему не сделано до сих пор? Видимо, необходимости раньше у тех же ОМ просто не было (они-то в основном встроенными системами занимаются). Так что GUI будем дорабатывать.

Можно ли отловить сообщение о закрытии окна нажатием кнопки с крестиком в его верхнем правом угле?
Нужно выполнить определенные действия после его закрытия.

Я проверял какие сообщения получает Views.View, но никаких особенных сообщений при закрытии окна ему не посылалось. Ну, разьве только что последним сообщением посланным к Views.View всегда было Controllers.MarkMsg. Вобщем, решение этой задачи надо искать не в сообщениях к View.

Бросте на форму якорь и установите его notifier.

Что такое якорь?

Ну, Anchor из SqlControls.

Ещё нужно запретить закрытие по крестику, если нарушены некоторые условия.
Якорь тут не поможет. Кто-нибудь такое уже реализовывал?

На ум приходит только WinApi по след. рецепту: когда условия нарушены, то устанавливаем в стиле окна отсутствие кнопки закрытия. Когда не нарушены, то возвращаем.
Или убираем крестик вообще, а закрытие окна разрешаем только по кнопке "Закрыть".

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

На сколько я помню из дельфи, есть такое системное событие, которое в этой самой дельфе называется OnCloseQuery. На сколько я понмаю, это не дельфовый прибамбас, а одно из системных сообщений среды. В общем где-то внутри оно должно сидеть. Крестик тоже можно убить, но это сложнее.

Да, естественно, можно ещё просто поставить перехватчик на окно и обрабатывать WM_CLOSE_QUERY, возвращая "нельзя закрывать". Для этого нужно запомнить текущую оконную процедуру диалога, подставить свою как перехватчик. Я что-то для этой цели вводил в MtWindows, насколько помню за давностью лет Посмотрите там.

По крайней мере, он может спросить, действительно ли надо закрыть окно.
А если очень хочется можно и переоткрыть.

Я подумал над этим и обнаружил, что окно в Ящике можно закрыть шестью разными способами.
1. Нажатием на кнопку "Закрыть".
2. Нажатием на "крестик".
3. Двойным кликом по верхней левой кнопке окна (не помню, как она называется).
4. Клик по верхней левой кнопке и выбрать в меню пункт "Закрыть окно".
5. Нажатием CTRL+F4.
6. Закрыв родительское окно.

Понятно, что все эти действия в конечном итоге приводят к посылке диалогу сообщения о закрытии. Контролировать закрытие я могу (на данный момент) только в первом пункте, потому что в данном случае сообщение о закрытии посылаю я сам.
А вот как быть в остальных случаях. Этот вопрос ещё интересен и в аспекте Линукс-версии Ящика.
По идее, надо бы встать на пути сообщения, причём не выходя за границы механизмов Ящика и не опускаясь до операционной среды.



Да, это железный вариант Особенно если учесть, что в Ящике окна открываются довольно быстро, и мерцания наверняка не будет. Пожалуй, я так и сделаю.



Ага, посмотрел, есть такое, но чего-то с наскоку не получилось, вызов

приводит к тряпу. У вас, случайно, какого-нибудь примерчика не осталось, как правильно использовать эту штуку?

Устанавливаемая процедура должна иметь сигнатуру MtWindows.CloseNotifier. Если Notifier вернёт canClose = FALSE, то окно не закроется.
OnClose можно вызвать для одного окна только один раз, потом нужно отключить с пустым notifier="", и только после можно вызывать для этого окна ещё раз.
В качетсве wnd можно передать 0, OnClose сама достанет активное окно.
Вроде бы всё...

Точно, спасибо, заработало. Тряп был как раз при втором вызове.
P.S. Ух ты, обработчик повесился на главное окно Ящика и не даёт его закрыть. Может, это и к к лучшему

Всё-таки астрал возвращает меня к этой проблеме Видимо, в мозгу нет ответа на какой-то Самый Главный Вопрос.

Повесить свой обработчик на окно для отлова сообщения о закрытии - самая (для меня) естественно напрашиваемая схема. Но как-то не уляжется никак; кажется, что это решение однобокое. Всё же идеология Ящика, как фреймворка с обратными вызовами немного про другое, и прямолинейное влезание в механизм передачи сообщений суть некошерно. Тут как минимум получается зависимость от платформы. А если решать архитектурно, то ничего, кроме своей обёртки вокруг стандартной формы, в голову не приходит. По идее, это правильный ход, потому что нет встревания в нормальный ход вещей, а есть надстраивание системы, усиление её своими наработками. Как думаете?

Извините за сумбурность, пишу, чтобы как-то упорядочить мысли - как говорится, в правильно поставленном вопросе содержится 50% ответа

Иван, обёртка на форму не поможет... Ведь форма в ББ - это самое обычное отображение. К понятиям "окно", "открытие", "закрытие" она отношения не имеет.

Это большой пробел в ББ - там есть верхний уровень абстракции: документы безотносительно к окнам. А на уровень ниже - работа с окнами и растровое рисование на них - никаких абстракций введено не было (ребята просто сэкономили ресурсы на обширной задаче, которая была им не актуальна). Windows не в счёт - это слой, построенный исключительно в той мере, в какой он нужен для более высокого уровня документов.
Поэтому единственный способ выходить на уровень окон и растра (пока) - это работать с API операционной системы.

Вариант с обработчиком не прошёл, т.к. в MDI-режиме обработчик цепляется за главное окно приложения. Нашёл вручную хэндл дочернего окна, но обработчик так и не повис на нём. Пока не особо хочется разбираться, т.к. это явный шаг в сторону Windows.

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