For myself, It would be logic if MeasureOverride calculates the size of the FrameworkElement and ArrangeOverride just positions the child elements. But ArrangeOverride does not only arrange the child elements. It does also calculate the size of the FrameworkElement again which I do not understand. Why can't MeasureOverride calculate the final size and thats it?
Asked
Active
Viewed 653 times
2 Answers
1
Because your element is potentially not the only one on the screen.
Layout is not that simple. WPF has to work out the actual physical space it has to use, then calculate how much space each element wants, scale the requested amount if it can, then apply it. Additionally some elements may want to make changes based on the exact amount of space allocated.
This previous answer of mine gives it to you as an analogy.
-
Thank you. Especially the linked answer is good. Do you have an example, where the final size differs from what MeasureOverride returns? – Sam May 04 '14 at 10:51
-
@Sam No I don't have an example to hand, but you could probably fake it (and examine the result) by returning a very large size from MeasureOverride for an element that is contained within something that is constrained to an artificially small area (i.e. it is absolutely sized and positioned). – slugster May 04 '14 at 10:53
1
If you implement your own Panel, with your own layout algorithm and in your ArrangeOverride() call
child.Arrange(rect1)
with rect1 being different than the child's DesiredSize then the system may arbitrarily decide to ignore rect1 size and use something different. I've seen DesiredSize being used, I'm not sure if it's always the case. I'd say that this is something resembling a bug :)
If rect1 is calculated in the MeasureOverride() pass of the Panel then a workaround for this behavior is to call Measure() on the child for a second time passing size of rect1, so DesiredSize of the child is recalculated before the Arrange() pass.
Pragma
- 31
- 3