コメントに答えて、フレームを使用する理由を提供します。
フレームは、設計時に既存のコンポーネントをより高度なコンポーネントに組み合わせることで、GUI の構成要素であると考えています。Delphi 5 より前はTCustomPanel、子コントロールを持つ子孫を使用し、これを新しいコンポーネントとして登録して、フォームにドロップする準備ができていました。フレームを使用すると、手間がかからずに同じことができます。
必要な機能だけを開発することに専念できます。正しく行うと、それらをタブ コントロール シート、モーダルまたはモードレス ダイアログ、MDI 子フレーム、および標準フレームに埋め込むことができます。それらのいくつかを 1 つのフォームに追加することもできます。これは、埋め込みフォームではおそらくできないことです。ポイントは、再利用性を最大限に高めるには、階層化されたアプローチがしばしば必要であり、フレームがそれを支援するということです。
フレームは、外出先から埋め込むのに適しています。キャプション バーと境界線を表示しないようにフォームを調整する必要があります。通常は、フォームをオーバーライドし、CreateParams()それに応じてウィンドウ スタイルを調整します。インスペクターには、埋め込みフォームには意味をなさないフォーム プロパティがたくさんあります。私見では、十分な最も基本的で一般的なエンティティを使用する必要があります。フォームは、埋め込み用のコントロール コンテナー以上のものです。
OTOH フォームの埋め込みにはない、フレームの埋め込みのデメリットについては知りません。
編集：
フレームにないOnCreateまたはのようなイベントに関するコメントがあります。OnShow実際には、フレームのもう 1 つの利点は、イベント ハンドラーにはパラメーターがないため、必然的に多くのものがフォームにハードコーディングされることだと思います。
ユーザーごとの設定の場合を考えてみましょう: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;
GUIの組み込みフレームを検討する際の参考になれば幸いです。
フレームの開始を制御するには、PageControl と組み合わせることを検討してください。
マンツ
動的に挿入されるフォーム/フレームの場合、個人的にはフレームよりも埋め込みフォームを使用することを好みます。いくつかのバージョンで、alClient に設定されたフレームを編集すると、編集ごとにフレームのサイズが変更され、フレームの右側に配置されたコントロールの位置が変更されました。埋め込みフォームを使用している場合、これは起こらなかったので、切り替えました。この問題は、新しいバージョンの Delphi で修正されていると思います。
通知イベントを介して埋め込みフォームに情報を渡すことができないという Mghie の以前の指摘に強く同意します。これを解決するために、私は通常、通信用の各組み込みフォームに一連のインターフェースを実装します。これにより、コードが非常に簡素化され、さまざまな種類の埋め込みフォーム/フレームを処理する単一の「コンテナー」を持つ、より一般的な実装が可能になります。このいくつかの例は、私が設計したウィザード フレームワークの一部として私のブログで入手できます。
数年前、私たちのアプリケーションの 1 つについて同じ決定を下しました。埋め込みフォームに見えるようにしたかったのです。最初にフレームを使用し、それを管理するクラスを作成しました。
後で、 LMDToolsのTLMDDisplayForm コンポーネントを見つけました。これにより、内部にフォームを埋め込む作業が非常に簡単になり、使用するコードが減り、より多くの機能が得られました。
フレームからフォームに変更した主な目標の 1 つは、アプリケーションのいくつかのタスクに使用する OnCreate、OnShow、OnActive などの TForm のいくつかのイベントが欠落していることでした。 .
フォームを使いたい場合は、基本バージョンが無料であることに加えて、タスクを簡単にするLMDToolsを使用することをお勧めします:-)
両方使うべきだと思います。たとえば、dbnavigator、dbgrid、データソース コンポーネントを備えた「標準」フレームは、典型的なデータ ブラウジングに非常に便利です。そのようなコンポーネントを毎回挿入する代わりに、データを (JVCL を使用して) いくつかの形式にエクスポートする機能も備えたフレームを挿入します... しかし、デザイン時に表示したいものはわかっているので、非常に簡単なルール: 設計時にわかっている場合はフレームを使用し、そうでない場合は埋め込みフォームを使用します。
ただし、フォームは埋め込み用に設計されていないことに注意してください。それらをそのように使用すると、それは不自然です（吸血鬼が80歳の娘を埋めたときに述べているように、彼女は30歳のように見えました：D）。埋め込まれたフォームは、それを所有するフォームについてほとんど知らず、(論理的に) 埋め込まれていないと想定することもできます。
それを補完するために、フレームはコンポーネントであるため、フォームに埋め込まれた (所有された) 場合、フォームはそれを認識し、フレームはフォームを認識します (そのメソッドとプロパティを使用できます。埋め込まれたものもそれを行うことができますが、追加のコーディングが必要です)
おそらくエンバカデロは、TEmbeddableForm またはそのような目的のためのインターフェイスを作成することによって、私たちに手を差し伸べることができます
よろしく、 アルバロ・カスティエロ
フレームは、フォーム内で「サブフォーム」を複数回繰り返したい場合に適しています。埋め込みフォームは MDI/Tabbed インターフェースを使用するためのより良いソリューションであるため、タブ付きインターフェースには使用しません。