Delphi, рамки против форм. Что для интерфейса multi-документа?

вчера я начал обсуждение "MDI vs tabbed interface". Я спросил, следует ли мне продолжать разрабатывать приложение на основе MDI или вставлять дочерние формы во вкладки. Кто-то указал, что вместо этого я должен использовать TFrames... Мой вопрос: почему?

каковы плюсы использования TFrames при встраивании формы поверх TFrame? Пока я ничего не знаю, переключение потребует только переписать некоторые части кода...

(Я не собираюсь использовать встраивание в время дизайна в любом случае!)

спасибо заранее

7
delphi frames mdi tframe

7 ответов

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

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

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

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

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

Edit:

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

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

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

11

может быть, вы найдете некоторые ответы в этой теме: gui-design-несколько форм-vs-simulated-mdi-tabs-vs-pagecontrol

5

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

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

Манц

2

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

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

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

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

1

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

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

1

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

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

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

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

с уважением, Альваро Кастьелло!--1-->

0

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

-1