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

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

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

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

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

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

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

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

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

Фрейм использует самую быструю загрузку и без задержки при создании фрейма.

Но у фрейма должен быть родитель, чтобы встроить его. Недостаток: не было инициировано событие 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 для управления открытием фрейма.

Manz

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

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

В дополнение к этому, Альваро Кастиелло