лучшие практики для жестко запрограммированных размеров в XAML

Question

Мне известно, что в WPF вы хотите, чтобы размеры элементов управления были как можно более гибкими, чтобы они могли перемещаться и расширяться в зависимости от их контекста (как в CSS).

Но большинство примеров кода, с которыми я сталкиваюсь, имеют размеры жесткого кодирования, такие как высоты в этом примере:

<Grid.ColumnDefinitions>
    <ColumnDefinition Width="0.5*"/>
    <ColumnDefinition Width="0.5*"/>
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
    <RowDefinition Height="31"/>
    <RowDefinition Height="31"/>
    <RowDefinition Height="31"/>
</Grid.RowDefinitions>

Не является ли присвоение высоты «31» каждой строке плохой практикой, которую не следует подражать? Или есть причина для этого? Или, может быть, авторы создают эти примеры в режиме конструктора и просто не очищают жестко закодированные высоты.

Есть ли у кого-нибудь лучшие практики в отношении определения размера элементов (особенно в отношении использования * синтаксиса), которым люди, начинающие с XAML, могут следовать, чтобы развить хорошие привычки с самого начала?

Answer 1

В большинстве случаев лучше использовать динамические размеры, за исключением определенных случаев, как отметил Стефано. Вы должны помнить, что WPF - это довольно новая технология, и многие пытаются ее освоить. Обычно, изучая новую технологию, люди начинают с создания того, что они знают (например, пишут на C #, как будто это Java), а затем начинают писать код «правильным» способом только после того, как они немного научились. Всегда берите сообщения в блоге с зерном соли.

Однако, исходя из кода, который вы разместили, я предполагаю, что они использовали Blend для создания XAML. Это всегда делает глупые вещи, такие как добавление высоты строк и создание обоих столбцов "0.5 *".

Answer 2

Вообще говоря, в XAML рекомендуется использовать динамические размеры, потому что, как вы говорите, концепция WPF должна быть независимой от фиксированных размеров. В вашем конкретном примере я не знаю, требуется ли это от автора, помните, что все еще есть некоторые случаи, связанные с жестко закодированными значениями (возможно, пользовательская строка меню или панель, которую вы хотите сохранить неизменной в своем размере). Обозначение «2 *» означает, что значение будет вдвое больше, чем у других столбцов, и поэтому использование звездного обозначения в каждом столбце не очень полезно.

Если вы ищете примеры, я могу обратиться к этим двум сайтам (но если вы ищете в Google "WPF star size" или что-то подобное, вы найду других). Кроме того, если вы ищете очень хорошую книгу о WPF, я с уверенностью могу указать вам Windows Presentation Foundation Адама Натана . Это один из моих любимых, хорошо написанных, полных цветных примеров и охватывающих все аспекты WPF.

Answer 3

Иногда вы не можете уйти от явного определения размера, особенно когда вы работаете с активами дизайнера, которые обычно преобразуются в размерные пути в таком инструменте, как Expression Design. Если вы хотите создать элемент управления с явным размером, а затем развернуться и работать с ним как с объектом динамического размера, вам следует использовать Viewbox.

В WPF обертывание элемента управления размера в Viewbox позаботится о динамическом выполнении преобразований, чтобы оно масштабировалось должным образом. Это, вероятно, влияет на производительность, но я не знаю, насколько это хуже, чем динамическое определение размеров. В Silverlight нет Viewbox "из коробки", но вы можете использовать прототип Viewbox из Silverlight Toolkit, чтобы дать вам аналогичный опыт.