Delphi, фреймы против форм. Зачем многодокументный интерфейс?

Отвечая на комментарий, объясняющий причину использования фреймов:

Я бы считал фреймы строительными блоками графического интерфейса пользователя с комбинацией существующих компонентов во время разработки с более продвинутыми компонентами. До Delphi 5 можно было использовать TCustomPanel потомка с дочерними элементами управления и зарегистрировать его как новый компонент, готовый для добавления в форму. Рамки позволяют делать то же самое с меньшими хлопотами.

Они позволяют вам сконцентрироваться на разработке именно той функциональности, которая вам нужна, и не более того. Если все сделано правильно, вы можете затем встроить их в листы управления вкладками, в модальные или немодальные диалоговые окна, в дочерние фреймы MDI и в стандартные фреймы. Вы даже можете добавить несколько из них в одну форму - то, что, вероятно, нельзя сделать со встроенными формами. Дело в том, что для максимального повторного использования часто требуется многоуровневый подход, и фреймы помогают в этом.

Каркас подходит для встраивания с ходу. Форма должна быть адаптирована так, чтобы не отображать строку заголовка и границу, обычно можно переопределить CreateParams() и соответствующим образом настроить стиль окна. В инспекторе гораздо больше свойств формы, которые просто не имеют смысла для встроенной формы. ИМХО следует использовать самый простой и общий объект, которого хватит. Форма - это нечто большее, чем просто контейнер для встраивания.

OTOH Я не знаю каких-либо недостатков встраивания фрейма, которого не было бы во встраивании формы.

Изменить:

Есть комментарий относительно таких событий, как OnCreate или OnShow, которых нет в кадрах. На самом деле, я бы посчитал это еще одним преимуществом фреймов, поскольку у обработчиков событий нет параметров, поэтому многие вещи обязательно жестко запрограммированы в формах.

Рассмотрим случай настроек для каждого пользователя: в OnCreate доступно не так много информации, поэтому неизменно заканчивается использование константы или имени формы для раздела файла INI, что очень затрудняет или даже делает невозможным повторное использование формы или создать несколько его экземпляров. С другой стороны, с фреймами метод LoadSettings - очевидный способ сделать это, и он может нести необходимые параметры. Таким образом, управление возвращается туда, где оно принадлежит, контейнеру встроенного фрейма / формы. Повторное использование возможно только в том случае, если поведение можно изменить извне.

Для содержащихся объектов, которые не являются компонентами и требуют управления временем жизни, есть, например, AfterConstruction и BeforeDestruction.

Возможно, вы найдете ответы в этой теме: gui- design-multiple-forms-vs-simulated-mdi-tabs-vs-pagecontrol

Каркас используют максимально быструю загрузку и без промедления при создании каркаса.

Но у фрейма должен быть родитель, чтобы встроить его. Недостаток: не было инициировано событие onCreate или onShow. но вы можете позвонить с сообщением для триггера события onShow, например этого:

надеть приватную секцию кадра:

procedure CMShowingChanged(var M: TMessage); message CM_SHOWINGCHANGED;

а затем создайте такой код:

procedure TFrame1.CMShowingChanged(var M: TMessage);
begin
  inherited;
  if Showing then
  begin
    // .... put your code for onShowing is triggered
  end
  else
  begin
    // .... put your code for onHiding is triggered
  end;
end;

Надеюсь, что поможет вам подумать о встроенном фрейме для графического интерфейса.

Вы можете использовать комбинацию с PageControl для управления открытием фрейма.

Манц

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

Позже я обнаружил компонент TLMDDisplayForm из LMDTools, который упростил встраивание форм внутри него, уменьшив используемый код и у нас есть больше возможностей.

одна из основных целей, которую мы изменили с фреймов на формы, заключалась в отсутствии некоторых событий TForm, таких как: OnCreate, OnShow, OnActive, которые мы используем для некоторых задач в наших приложениях, помимо отсутствия некоторых свойств, таких как: ActiveControl и другие вещи, которые я не помню .

Если вы хотите использовать формы, я предлагаю вам использовать LMDTools, которые облегчают вам задачу, кроме базовой версии бесплатно :-)

Для динамически вставляемых форм / фреймов я лично предпочитаю использовать встроенные формы вместо фреймов. Несколько версий назад, когда можно было редактировать фрейм, для которого было установлено значение alClient, размер фрейма изменялся между изменениями, и любые элементы управления, которые были выровнены по правому краю фрейма, изменяли бы положение. При использовании встроенных форм этого не произошло, поэтому я переключился. Я считаю, что эта проблема теперь исправлена ​​в более поздних версиях Delphi.

Я полностью согласен с замечаниями Mghie, сделанными ранее относительно невозможности передать информацию во встроенную форму через события уведомления. Чтобы решить эту проблему, я обычно реализую серию интерфейсов в каждой встроенной форме для связи. Это действительно упрощает код и позволяет использовать более общие реализации, в которых у вас есть один «контейнер», который будет иметь дело со многими различными типами встроенных форм / фреймов. Несколько примеров этого доступны в моем блоге как часть созданной мной инфраструктуры мастера.

Я думаю, что нужно использовать оба. Например, у меня есть «стандартный» фрейм, в котором есть компоненты dbnavigator, dbgrid и datasource, что очень удобно для обычного просмотра данных. Вместо того, чтобы каждый раз вставлять такие компоненты, я вставляю фрейм, который также имеет возможность экспортировать свои данные (с помощью JVCL: D) в несколько форматов ... но я знаю, что я хочу отображать во время разработки, поэтому я предлагаю очень простое правило: если это известно во время разработки, используйте фреймы, в противном случае используйте встроенные формы.

Однако имейте в виду, что формы не предназначены для встраивания. Используя их таким образом, это неестественно (как заявляет вампир, когда хоронит свою 80-летнюю дочь, а она выглядела как 30: D). Встроенная форма мало знает о том, кому она принадлежит, и может также (логически) предположить, что она не встроена.

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

Возможно, Embarcadero может помочь нам, создав TEmbeddableForm или интерфейс для таких целей.

С уважением, Альваро Кастиелло

Фреймы хороши, когда вы хотите многократно повторить «подформу» в форме. Я бы не стал использовать их для взаимодействия с вкладками, поскольку встроенная форма - лучшее решение для использования интерфейса MDI / Tabbed.