Verständnisfrage FrameworkElement.ArrangeOverride
Hallo,
habe eine Verständnisfrage zu untenstehendem MSDN Beispiel zu FrameworkElement.ArrangeOverride.
[ Als Beispiel im folgenden angenommen: child.DesiredSize = 200 x 200 Einheiten ]
- MeasureOverride meldet als gewünschte Größe 200 x 200 Einheiten, da im Code
panelDesiredSize = child.DesiredSize;
}
return panelDesiredSize ;
- ArrangeOverride nutzt letzten Endes mehr Platz: Das child Element wird ab 50/50 (x/y) positioniert und hat nach wie vor eine Größe von 200x200.
(a) Also werden doch letzten Endes 250 x 250 Einheiten (je 50 + 200 Einheiten) an Platz benötigt?
(b) Müsste nicht genau dieser Wert, 250 x 250, schon von MeasureOverride als erwünscht gemeldet werden?
(c) Und müsste man in ArrangeOverride nicht überhaupt erstmal prüfen, ob man soviel Platz erhält, wie gewünscht?
Vielen Dank!
P.S.: Hier noch das vollständige Beispiel, aus
http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.arrangeoverride.aspx
public class PlotPanel : Panel
{
// Default public constructor
public PlotPanel()
: base()
{
}
// Override the default Measure method of Panel
protected override Size MeasureOverride(Size availableSize)
{
Size panelDesiredSize = new Size();
// In our example, we just have one child.
// Report that our panel requires just the size of its only child.
foreach (UIElement child in InternalChildren)
{
child.Measure(availableSize);
panelDesiredSize = child.DesiredSize;
}
return panelDesiredSize ;
}
protected override Size ArrangeOverride(Size finalSize)
{
foreach (UIElement child in InternalChildren)
{
double x = 50;
double y = 50;
child.Arrange(new Rect(new Point(x, y), child.DesiredSize));
}
return finalSize; // Returns the final Arranged size
}
}
Hallo,
Das Layoutsystem in WPF kann ganz schön tricky sein 😃 Ob MeasureOverride 250*250 zurückgeben müsste und ArrangeOverride nicht erst gucken müsste ob genug Platz ist ist, darüber kann man diskutieren. Es kommt stark drauf an wie man das Panel konzipiert
In WPF kann man problemlos überall zeichnen. Selbst wenn sich vorstellt ein Panel ist in der linken oberen Ecke mit 100100, dann ist es trotzdem möglich bei 200200 nen Child zu zeichnen. Ob es funktioniert hängt im Endeffekt davon ab wie ClipToBounds gesetzt ist und wie groß die sichtbare Fläche ist.
Wenn man das Panel aus dem Beispiel jetzt genau 200*200 groß macht, dann wird das Child über das Panel hinaus gezeichnet. Wenn man bei MeasureOverride die 50+ einrechnet, dann nicht. Das "Problem" hast du richtig erkannt, nur ist es in WPF wie gesagt keins, da man auch außerhalb des eigenen Controls zeichnen kann.
Beim Canvas ist es sogar so dass man es oft einfach ne Größe von 0*0 gibt damit man es nicht bei irgendwelchem Layout Sachen berücksichtigen muss. ist an sich ne ganz praktische Sache.
Wo wir grad bei Canvas sind: Das Canvas gibt beim Measure Aufruf im Prinzip jedem Child unendlich viel Platz, so das Children immer so groß werden wie sie wollen. Beim Arrange dagegen kriegen die Children dann genau den Platz den sie brauchen + verschoben um die Koordinaten die man durch Canvas.Top/Canvas.Left angegeben hat.
Beim StackPanel dagegen wird beim Measure maximal die Stackpanelgröße gegeben. Wenn man das normale vertikale StackPanel betrachtet, wird dort beim Arrange in horizontaler Richtung Unendlich als Größe des Childs gegeben.
Denke mit den Beispielen versteht man die Rolle von Measure und Arrange ein wenig besser.
Aber apropro unendliche Größe. Dein Beispiellink in der MSDN ist ja für .Net 3.5. Das ist auch gut so. Das Beispiel in ArrangeOverride für .Net 3.0 ist nämlich falsch! Dort wird beim MeasureOverride nämlich die Größe die übergeben wird als verfügbare Größe, der Einfachheit halber als Rückgabewert benutzt. Das ist fatal und kann zu Exceptions führen. Wenn ein Child vom Canvas z.b. unendlich als verfügbare Größe übergeben bekommt, und das Child gibt das einfach zurück, dann steht das Layoutsystem vor der Aufgabe zu bestimmen wie lang unendlich doch eigentlich in Pixeln ist 😉 An dieser Aufgabe versucht es sich natürlich erst gar net und wirft ne Exception. Nur so als Hinweis weil mir das grad beim Anschaun der Doku aufgefallen ist.
Baka wa shinanakya naoranai.
Mein XING Profil.
Hallo talla,
vielen Dank für deine Antwort.
Das man in WPF einfach überall hinzeichen konnte wusste ich nicht, aber amche ich damit nicht mein Layout kaputt? WPF rechnet doch insbesondere bei Arrange damit, dass ich mich auch an den Platz halte, oder? Ich weiß, dass bei MeasureOverride ein größerer Wert dem Elternelement signalisiert, dass es doch noch etwas Platz "locker machen" soll (wenn es z.B. scrollabr ist), aber bei Arrange ist der zur Verfügung gestellte Platz doch schon final, oder? Also mehr nutzen würde schon gehn, aber wäre nicht so geschickt, da man evtl. andersweitig gedachten Platz nutzt?
Hallo,
Das Elternelement bleibt ja an seinem Platz und wird korrekt gelayouted. Es sind ja die Child Elemente die über die Grenzen des Elternelement gezeichnet werden können. Diese haben was das Layout angeht, natürlich nur Bezug zum Elternelement. Ob da noch andere Elemente, die auf gleicher Ebene wie das Elternelement sind, verdeckt werden etc., ist denen vollkommen egal. Das kann natürlich schon nen ganz schönes Chaos geben wenn man net aufpasst. Deshalb ist das Canvas Panel auch das einzige wo es explizit erlaubt ist. Bei allen anderen wie Grid, StackPanel, WrapPanel etc. ist das ClipToBounds Property auf true und damit kann nicht außerhalb des Panels gezeichnet werden. Somit ergibt sich in der Praxis kein Problem mit dem Layout. Wenn man selber Panel entwickelt, muss man darauf natürlich achten.
Baka wa shinanakya naoranai.
Mein XING Profil.