8

WPF で Panel をサブクラス化し、独自のレイアウト作業を実装し、availableSize 引数で MeasureOverride に渡されるディメンションの Infinity または PositiveInfinity を取得する人々から、他にもいくつかの質問を見つけました。応答は一般に、「これは、必要なだけスペースを占有できることを意味します。無視して、すべての子の必要なサイズを合計し、それを返します。」

私の場合、使用可能なスペースを埋めるために動的にサイズ変更するコントロールを作成しているため、目的のサイズの本質的な概念はありません。availableSize全体を使用したいだけです。

ControlTemplate を構築すると、StackPanel 内にネストされ、コントロールにスクロールバーがなくても、利用可能な高さの無限大を取得し始めました。固定数に制限しただけでは、ウィンドウにクリップするだけです。ActualHeight を返そうとしましたが、循環的であるためうまくいきませんでした。完全なレイアウト パスを実行する前に ActualHeight はありません。つまり、常に 0.0 でした。

最初は、それが Infinity を渡す StackPanel であるとは知らず、参照ソースをしばらく掘り下げて役に立たず、最終的に VisualTreeHelper を使用して親を実行し、それらの ActualHeight を見て、StackPanel が高さがゼロでない最も深いもの。必要なコントロールは 2 つだけなので、DockPanel に変更しました。これは、StackPanel と同様に機能します。そして見よ、DockPanel は利用可能な高さの Infinity を渡さない。

しかし、それは回避策のように感じます。レイアウトの背後にある哲学と、スクロールバーのない標準的なコンテナーの 1 つが、必要なだけのスペースを確保できる理由をより深く理解したいと思います。それに対する「正しい」反応は何ですか？

4

2 に答える 2

2

これ：

使用可能なスペースを埋めるために動的にサイズ変更するコントロールを作成しています。

以下との悪い組み合わせ:

それは最終的に StackPanel 内にネストされました

「スペースを埋める」コントロールは、スタックパネル内にあってはなりません。どのくらいのサイズがいいと思いますか？

もちろん、ScrollPanel についても同じです。

于 2012-05-17T18:32:09.850 に答える
1

わかりました。他の人とオフラインでも話しましたが、これが私の理解の最善です:

LayoutTransform または RenderTransform を使用してより洗練されたレイアウトを実行したい場合、コントロールの測定/配置パスと実際のピクセル境界の間に間接性を追加し、スタックされたすべてのコントロールにできるだけ多くのスペースを占有できることを伝える動作画面上の実際のクリッピングされた領域から離れた表面にレイアウトしようとしているだけなので、彼らが望むように合理的です。

これはまだ「スクロール可能なもので StackPanel をラップする場合...」のカテゴリに該当するように感じますが、StackPanel の RenderTransform をいじり始めると、私の提案したバージョンでは availableSize がどうあるべきかは明確ではありません。(それよりも基本的なことですが、RenderTransform は、パフォーマンスのためにレイアウト メカニズムとは別に設計されているため、設計上 MeasureOverride と "うまく機能" しません... したがって、これが優れた議論であることはまだ明らかではありません。)

いずれにせよ、一部の選択されたアイテムが他の要素によって使用されていない残りを消費する StackPanel の動作を取得する方法は、DockPanel を使用することです。上または下、または 2 つのスタックの中間。

利用可能なスペースを均等に消費する複数の要素が必要な場合、それが Grid の目的だと思います。

しかし、原則的な観点からは、MeasureOverride を呼び出すときに StackPanel が向きの方向として Infinity を子に渡す理由をまだ理解していないと言わざるを得ません。StackPanel の親によって渡された実際の残りの未請求の利用可能なサイズを渡さない理由についての議論はありません。

于 2012-05-18T20:38:06.993 に答える