2009-08-07 3 views
2

Я смотрел на FrameworkElement.MesureOverride на MSDN, пытаясь понять механизм механизма компоновки. Я наткнулся на эту интересную ноту:MesureOverride возвращает больше, чем доступный размер?

Во время этого процесса дочерние элементы могут возвращать более крупный размер DesiredSize, чем исходный доступный размер, чтобы указать, что дочерний элемент хочет большего пространства.

Ok. У меня был рефлектор, поэтому я посмотрел в MesureCore, который вызывает MesureOverride, и я заметил, что из того, что я понял, возвращаемое значение MesureOverride всегда ограничено между 0 и доступным размером. Так что же с этим?

ответ

1

Детский элемент может просить больше места. Выполняется ли этот элемент родительским элементом до родительского элемента.

MeasureCore вызывает только MeasureOverride по адресу this. Вы только получаете очень небольшую часть истории. The Layout System начинается с звонка Measure на верхнем Panel в дереве элементов, который вызывает MeasureCore на this. Однако MeasureCore в FrameworkElement звонит MeasureOverride в нескольких местах.

Где вы видите его между 0 и доступным размером?

Edit: Re: «хорошо, последняя строка MeasureCore ...»

Как я уже говорил, вы смотрите на небольшую часть всего, что происходит.

  1. Все элементы управления имеют 1 очень распространенный способ запросить больше места, чем требуется на самом деле: Margin. Вам нужно будет написать настраиваемый элемент управления, чтобы запросить еще больше места.
  2. Ограничения, которые вы видите в MeasureCore, от того, что я могу сказать, что нужно сделать с ограничениями в MinWidth/MinHeight и MaxWidth/MaxHeight, если они установлены.

Так что, контроль - как говорится в документации - может запрашивать больше места, чем необходимо. Ни один из элементов управления по умолчанию, похоже, не делает этого за исключением своих Margin, и контейнеры, такие как панели, не должны его уважать. Большинство обстоятельств не используют то, что вы читаете в документации, потому что в большинстве случаев это не имеет смысла ни с точки зрения родителя ребенка.

Если вы создали UserControl, избавившись от Width и Height значений в XAML и переопределить MeasureOverride вернуть произвольные Size, а затем поместить его экземпляр в Canvas, вы увидите его отображение на Size вы вернулись ,

Эта особенность системы компоновки может быть полезна, если вы создаете пользовательские панели и пользовательские элементы управления или пользовательские элементы управления, но в противном случае, вероятно, нет. Но он есть. Документация верна.

+0

ну, последняя строка MesureCore возвращается новый размер (Math.Max ​​(0.0, width), Math.Max ​​(0.0, height)); (это единственный оператор возврата) и немного раньше, что есть пара ifs, например if (width> availableSize.Width) width = availableSize.Width; – subb

0

Если вы возвращаете Size>availableSize из собственного MeasureOverride метода FrameworkElement.MeasureCore (вызов ваш метод) будет помнить, но DesiredSize будет установлен = availableSize. Это гарантирует, что дочернее управление будет подходящим для (например) ячейки сетки с явно заданной шириной/высотой. НО, потому что FrameworkElement.MeasureCore запоминает ваш «unclipped» DesiredSize, в ArrangeOverride вы должны получить параметр = ваш оригинал DesiredSize. В результате этого ваш контроль «фактически» устраивает детей в соответствии с его оригинальным DesiredSize, но реализация FrameworkElement будет зависеть от вашего контроля над такой родительской сеткой. Метод отсечения бетона будет зависеть от фактических значений свойств, таких как Horizontal/VerticalAlignment (свойства вашего контроля).

Смежные вопросы