コメントに答えて、フレームを使用する理由を提供します。
フレームは、設計時に既存のコンポーネントをより高度なコンポーネントに組み合わせることで、GUI の構成要素であると考えています。Delphi 5 より前はTCustomPanel
、子コントロールを持つ子孫を使用し、これを新しいコンポーネントとして登録して、フォームにドロップする準備ができていました。フレームを使用すると、手間がかからずに同じことができます。
必要な機能だけを開発することに専念できます。正しく行うと、それらをタブ コントロール シート、モーダルまたはモードレス ダイアログ、MDI 子フレーム、および標準フレームに埋め込むことができます。それらのいくつかを 1 つのフォームに追加することもできます。これは、埋め込みフォームではおそらくできないことです。ポイントは、再利用性を最大限に高めるには、階層化されたアプローチがしばしば必要であり、フレームがそれを支援するということです。
フレームは、外出先から埋め込むのに適しています。キャプション バーと境界線を表示しないようにフォームを調整する必要があります。通常は、フォームをオーバーライドし、CreateParams()
それに応じてウィンドウ スタイルを調整します。インスペクターには、埋め込みフォームには意味をなさないフォーム プロパティがたくさんあります。私見では、十分な最も基本的で一般的なエンティティを使用する必要があります。フォームは、埋め込み用のコントロール コンテナー以上のものです。
OTOH フォームの埋め込みにはない、フレームの埋め込みのデメリットについては知りません。
編集:
フレームにないOnCreate
またはのようなイベントに関するコメントがあります。OnShow
実際には、フレームのもう 1 つの利点は、イベント ハンドラーにはパラメーターがないため、必然的に多くのものがフォームにハードコーディングされることだと思います。
ユーザーごとの設定の場合を考えてみましょう:OnCreate
利用できる情報があまりないため、常に INI ファイル セクションの定数またはフォームの名前を使用することになり、フォームの再利用や作成が非常に困難または不可能になります。それのいくつかのインスタンス。一方、フレームでは、メソッドLoadSettings
がそれを行うための明白な方法であり、必要なパラメーターを運ぶことができます。そうすれば、コントロールはそれが属する場所、つまり埋め込まれたフレーム/フォームのコンテナーに戻されます。再利用性は、動作を外部から調整できる場合にのみ可能です。
コンポーネントではなく、ライフタイム管理が必要な含まれるオブジェクトの場合、たとえばAfterConstruction
とがありBeforeDestruction
ます。