2015-02-20 6 views
2

Я работаю над несколькими проектами Wpf. В каждом проекте нам нужно было стилизовать элементы управления Wpf по умолчанию (например, Button). Каждый раз, когда мы запускали новый проект, мы строили наши шаблоны и стили с нуля - или просто копировали их с одной сборки на другую.Повторное использование стилей и шаблонов

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

Пример модификации (опять же с использованием кнопки управления): Нам нужно изменить кисти разных состояний кнопок, чтобы они соответствовали требованиям к приложению.

  | Hover-Brush | Click-Effect | 
|-----------|-------------|----------------| 
| Project A | Orange  | Light Orange | 
| Project B | Blue  | Light Blue  | 
| ...  | ...   | ...   | 

Для того, чтобы достичь своей цели, мне нужно абстрагировать этой samplestyle:

<Style TargetType="{x:Type Button}"> 
    <Setter Property="Template"> 
     <Setter.Value> 
      <ControlTemplate TargetType="{x:Type Button}"> 
       <Border x:Name="Border" Background="Orange"> 
        <!-- Further elements required to build our button --> 
       </Border> 

       <ControlTemplate.Triggers> 
        <Trigger Property="IsMouseOver" Value="True"> 
         <Setter TargetName="Border" Property="Background" Value="LightOrange" /> 
        </Trigger> 
        <!-- Further triggers for other effects --> 
       </ControlTemplate.Triggers> 
      </ControlTemplate> 
     </Setter.Value> 
    </Setter> 
</Style> 

Как вы можете видеть цвета жёстко и благодаря тому, что стиль не подлежит повторному использованию. Моя идея - использовать прикрепленные свойства, которые стиль может использовать для привязки. Если бы я определить вложенное свойство HoverBrush и использовать его для связывания нового стиля будет выглядеть следующим образом:

<Style TargetType="{x:Type Button}" 
     x:Key="DefaultButton"> 
    <Setter Property="Template"> 
     <Setter.Value> 
      <ControlTemplate TargetType="{x:Type Button}"> 
       <Border x:Name="Border" Background="{TemplateBinding Background}"> 
        <!-- Further elements required to build our button --> 
       </Border> 

       <ControlTemplate.Triggers> 
        <Trigger Property="IsMouseOver" Value="True"> 
         <Setter TargetName="Border" 
           Property="Background" 
           Value="{Binding Path=styles:Brushes.HoverBrush, 
               RelativeSource={RelativeSource TemplatedParent}, 
               FallbackValue={StaticResource SomeBrush}}" /> 
        </Trigger> 
        <!-- Further triggers for other effects --> 
       </ControlTemplate.Triggers> 
      </ControlTemplate> 
     </Setter.Value> 
    </Setter> 
</Style> 

Этого стиль позволит сократить разметку, необходимую для новой темы в другом приложении к чему-то вроде этого:

<Style TargetType="{x:Type Button}" 
     BasedOn="{StaticResource DefaultButton}"> 
    <Setter Property="styles:Brushes.HoverBrush" 
      Value="LightOrange" /> 
</Style> 

Итак, мои вопросы будут: Существуют ли разные подходы? Вы видите негативные стороны моего подхода? И самое главное: знаете ли вы более эффективные способы достижения своей цели?

ответ

1

Поскольку каждое новое приложение будет тематическим, я бы просто определил некоторые кисти в Generic.xaml и сделал {DynamicResource HoverBrush}.

Часть XAML для стиля кнопки может остаться таким же, и в каждом новом приложении вам просто необходимо будет определить новые кисти с теми же именами в Generic.xaml

+0

Это потребовало бы мне определить каждый цвет в каждом приложении , даже если нам понадобятся лишь незначительные изменения, не так ли? – Thorakas

+1

Да, это хороший момент, ваш путь позволяет вам изменить только одно свойство стиля кнопки, если вам нужно небольшое изменение. Я не знаю, либо вы обнимаете/включаете библиотеку классов, содержащую определения для прикрепленных свойств, либо копируете мастики в Generic.xaml. У кого-то есть свои привилегии/недостатки, я думаю. Вы можете подумать об определении этих кистей в многоразовом словаре ресурсов (который вы объедините в свой Generic.xaml в каждом новом ap), а затем просто определите локальную кисть с тем же именем, чтобы «перезаписать» один цвет (из-за природы DynamicResource) – CodeOtaku

+1

Благодарим вас за разъяснение. Я определенно посмотрю на эту попытку. – Thorakas