Monday, January 12, 2009

WPF Layout Woes - MeasureOverride killed Schrödinger's Cat

A struggle I'm currently having with layout in WPF reminds me of the Observer Effect in physics. It turns out that calling Measure() on a child object has side effects. You would think that the measuring phase of layout would simply involve asking the child how big it wants to be. Instead, you need to pass it a size constraint.

Normally, that would not be a problem, but what if you want to size a set of children based on their relative desired sizes? Catch-22. You can't call Measure() on a child without knowing the maximum size you want it to be. And, in my situation, I don't know what size I want it to be without first measuring it. And, once you have measured an objected, its size "sticks" - changing it when you do Arrange() only alters the size of the clip rectangle (an important distinction if the child actually can be variably sized - such as content within a ScrollViewer).

Very frustrating.

I have found a fairly complicated way of working around the isue, but it seems like a fundamental (if not often encountered) flaw in the way WPF layout works.

4 comments:

  1. you can pass an infinite size or return a greater size than the constraint

    ReplyDelete
  2. You would think that would work, and of course I tried it, but it doesn't solve my particular problem. The child will take up the extra given space and not give it back even if it is told it has less space when you do Arrange().

    ReplyDelete
  3. > I have found a fairly complicated
    > way of working around the isue

    What way did you find? Even if it is complicated, I'd like to know it.

    ReplyDelete
  4. I have the exact problem as Mike said. But i don't know the work around for this. Do you guys please post it here.

    ReplyDelete