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

Я знаю, что в 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, могут следовать, чтобы с самого начала выработать хорошие привычки?


wpf xaml silverlight
person Edward Tanguay    schedule 27.01.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

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

person Stefano Driussi    schedule 27.01.2009

arrow_upward
1
arrow_downward

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

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

person Bryan Anderson    schedule 27.01.2009

arrow_upward
0
arrow_downward

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

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

person Daniel Crenna    schedule 29.01.2009