「パネルの代わりに TSpTbxMultiDock を使用する必要がありますか?なぜですか?」
簡単に言えば、TSpTBXMultiDock
コンポーネントは s のみを処理およびドッキングするように作成されているためTSpTBXDockablePanel
です。
長い答えは、ドッキングコードはドッキングしているコントロールの特定のメソッド/プロパティに依存しているためTSpTBXMultiDock
、コンポーネントはTSpTBXDockablePanel
sのみを処理およびドッキングするように作成されているということです。を参照してください。これは、プロパティとメソッドにアクセスします。TSpTBXCustomDockablePanel.SetParent
TSpTBXCustomMultiDock.
UpdateDockablePanelsDockPos
ClientAreaWidth
ClientAreaHeight
つまり、ドッキングとレイアウトのコードは、特定の情報を認識し、ドッキングされたコントロールに特定の処理を要求する必要があります。これを行う最も簡単な方法は、ドッキングできるコントロールのタイプを、必要なインターフェイスを宣言および実装する特定のクラスの子孫に制約することです (インターフェイスを大まかに使用すると、(クラス)interface
は宣言されず、メソッドの非公式なセットにすぎません) / プロパティ。)
UpdateDockablePanelsDockPos
コードをざっとざっと見てみると、本当に重要なのは最初の だけだと思います。私は何かを逃したかもしれません。ただし、このメソッドは、ドッキングされたすべてのパネルのリストを取得し、それぞれの を更新しますDockPos
。これは、パネル内のドッキングの 1 次元の位置です。つまり、水平パネルの場合は左/水平の開始点であり、垂直パネルの場合は上部/垂直の開始点です。また、合計を更新して、パネルが必要な大きさ、または選択した場合に大きくなる可能性があることを認識します。
私はあなたの質問に答えたかどうか確信が持てません。私は正しい答えを与えたと思いますが、役立つ答えではありません (上記は技術的な理由であり、概念的な理由ではありません)。TBX -> SpTBX の移行に苦労していて、ツールバーとドッキング可能なパネルの両方を処理できるドッキング領域が必要なため、これを求めていると思います。幸いなことに、これらは両方とも 2 番目の質問につながります...
「TSpTbxMultiDock にツールバーを配置できますか?」
私はここで記憶されている領域に足を踏み入れていますが、答えのこの部分が正しいことを保証することはできません。かなり前にアプリを TBX から SpTBX に変換したためです。
まず第一にTSpTBXToolbar
、ドッキング可能パネルに を配置することはできません。を にドッキングすることもできませTSpTBXDockablePanel
んTSpTBXDock
。ツールバーはドックにドッキングでき、ドッキング可能なパネルはマルチドックにドッキングできます。
この理由は当て推量ですが、ドッキングされた 2 つのコントロールの動作とその目的が異なるためだと思います。
ツールバー:
- SpTBX アイテム(通常の VCL コントロール、ボタンなどではなく、ボタン、ドロップダウンなど) を含むことを意図しており、フォームのサイズが変更されたりツールバーが縮小したりすると、ツールバーからメニューなどに動的に変更できます。
- スタック: (常に互いに隣接して配置されるドッキングされたパネルとは異なり) ツールバー間に任意の量のスペースがあるだけでなく、ツールバー間にスペースを設けることができます。ユーザーが置いた場所ならどこにでも座ります。また、複数の列に並んでいることが多く、1 つのドックが拡張されて複数の列が含まれます。
- 縮小するように設計されている:フォームが小さすぎたり、ユーザーがツールバーを別のツールバーにドラッグしたりする可能性があり、ツールバーには可能なアイテムのみが表示され、他のアイテムを非表示にするか、シェブロン (小さな >> ボタンで開く) が表示されます。他の項目を含むメニュー。)
ドッキング可能なパネル:
- 標準の VCL コントロールを含む複雑なコントロールを保持するためのものです。これらは、複雑なドッキングされたフォームを構築するためのツールバーおよびドッキング システムと互換性のある方法として意図されています。(フレームとして設計し、クライアントがフレームをドッキング可能なパネルに合わせます。)
- まれに複数列に並んでいます。 これは UI 実装者の責任ですが、多数のパネルを隣り合わせにドッキングすると、フォーム スペースが急速にいっぱいになる可能性があります。ドッキング可能なパネルでは LimitToOneRow をオンのままにして、1 つのディメンションのみを埋めることができるようにします (つまり、フォームの左側と右側では、ドッキング可能なパネルはそれぞれの左右ではなく、上下にのみ配置できます)。他の。)
- サイズ変更の動作は異なります: それらは常に隣接しており、その間に隙間がなく (ツールバーはどこにでも配置できます)、通常は 1 つまたは複数のパネルを引き伸ばしてドック全体のサイズを埋めます (ツールバーは、
MenuBar
が設定されていない限り、そうではありません (以下を参照)。 )) 実際、ツールバーは拡大ではなく縮小するように設計されており、シェブロンとドロップダウン メニューが表示されます。パネルにはその動作がありません。
その転換の後、あなたの質問に戻ります。アプリを変換していたとき、2 つのタイプを可能な限り混在させるために、ユーザーがツールバー、ドッキング可能なパネル、そして再びツールバーがあるようなレイアウトを作成したい場合はどうなるのだろうと思ったことを覚えています。これを行うには、ドック、次にマルチドック、そして再びドックが必要になりますが、実際にはこれにより、ユーザーは非常に複雑で紛らわしいレイアウトを作成できるようになります。ドッキング可能な UI の問題点の 1 つは、多くのユーザーが UI を混乱させてしまい (正直なところ、驚くかもしれません)、不要な場所にアイテムを誤って移動したりドッキングしたりできることです。(たとえば、メニュー バーを上部に制限することをお勧めします。移動できないようにします。混乱を招くだけです。)
現在の設計では、メイン ウィンドウの両側に 2 つのドックがあります。1 つの通常のドックと、その隣 (フォームの中央に近い) のマルチドックです。その結果、メニューや通常のツールバーなどのすべてのツールバーは、ウィンドウの端にしかドッキングできなくなります。ドッキング可能なパネルは、それよりもフォームの内側に近くなります。ドックとマルチドックのペアをフォームの各端に並べて配置すると、両方のタイプのコントロールをフォームの任意の側にドッキングできますが、ツールバーは常にフォームの端に配置するように制限されます。実際、これは UI に意味があります。ドッキング可能なパネルは、ツールバーよりも内部に複雑なものを含む傾向があり、より中央のコントロールであるということになります。もちろん、フォームの特定の端にドッキング可能なツールバーではなく、ドッキング可能なパネルしかない場合は、
テキストとして書かれているため、前の 2 つの段落 (このスキームがどのように機能するか、およびなぜこれが良い/良いのか) を説明するのは困難です。実際に試して、ユーザーの動作を理解する必要があります。ただし、基本的には、フォームに両方のタイプのドックをTSpTBXMultiDock
配置し、 を通常のツールバー ドックの「内側」または「内側」に配置することをお勧めします。うまくいけば、この画像が役に立ちます。
他の
次のプロパティに興味があるかもしれません:
DockableTo
(ツールバーとドッキング可能なパネル): ツールバーまたはパネルがドッキングできる側 (上、下、左、右) を制限します。これを使用して、一部のコントロールを特定の特定のドックにのみドッキングできるようにします。たとえば、上部にのみドッキングするメイン メニューです。
DefaultDock
(繰り返しますが両方): ユーザーがドラッグ ドッキングではなくダブルクリックしてドッキングすると、どこに移動しますか?
CurrentDock
:すでにこれを見つけたと思いますが、デザイナーで設定して、ドック間でツールバーまたはパネルを移動し、実行時に読み取ります(または、プログラムで特定のドックに移動したい場合は、実行時に設定すると思います)。
DockMode
: ツールバーまたはパネルをフローティング (ドッキングを解除して独自のウィンドウにする) できるかどうかを制御します。これには、ドックを変更できるかどうかも含まれます。これを使用する例は、メインメニューの制約です。
FixedDockSize
(パネルのみ): ユーザーまたは上記のドッキング コードによるパネルのサイズ変更を停止します。
MenuBar
(ツールバーのみ): ツールバーの動作が若干異なります。常にドックの全幅を占有し、他のツールバーをその隣にドッキングすることはできないと思います。また、アイテムのレンダリング方法がわずかに変わる場合もあります。