1

Just wondering ... for shared definitions (e.g. colors, brushes), is it better to put it in resourcedictionary (in XAML) or code-behind (C#)? Assumption: usage of these definitions are in both XAML and code-behind.

For example colors definition, it seems like every tutorial I read off the internet will put it in resourcedictionary - <SolidColorBrush x:Key="Color1" Color="#cccccc"/>.

However, won't it be better if it is put in code-behind as public static SolidColorBrush Color1 = new SolidColorBrush(#cccccc); and accessing it in XAML via x:Static extension - {x:Static local:MyColor.Color1}?

In this way, I can get the nice intellisense in both XAML and code-behind. In addition, avoid the hard coding of the key in the code behind - SolidColorBrush Color1 = FindResource("Color1") as Style.

Edit: My objective is to:

  • have the nice intellisense in both xaml and codebehind
  • unified the definition to ensure no chance of runtime error due to hard-coding
  • better performance

So that when the designer access to Background="{StaticResource Color1}" in the XAML code, it is the same thing as TextBlock.Background = Color1; in the codebehind. And when someone were to change the x:Key="Color1", at least there will be a compile error.

CCovey
  • 799
  • 1
  • 10
  • 17
SimonSays
  • 477
  • 5
  • 13
  • If you put them in a ResourceDictionary, it's a lot easier to swap the entire dictionary out for another one and change the look. Plus you can merge ResourceDictionaries in the xaml easier than in code. – CoderForHire Apr 09 '15 at 18:35

2 Answers2

0

Personally I'd probably put it on the Resources side, because then you can use blend to visually see what is happening when you change the designer. This is great if your application takes a long time to load up.

Check this out for accessing resources from the code behind so you still have it in only one place. Accessing a resource via codebehind in WPF

Edit: If you are using a resource dictionary it will display in blend/design mode without having to start your application. If your application takes a while to load up, then this saves a lot of time modifying the color, starting, checking, then stopping your application. I can't speak to it's performance implications, but in general if you can do something in XAML and not the code behind it's best to do it there.

Community
  • 1
  • 1
thinklarge
  • 672
  • 8
  • 24
  • Using `resourcedictionary` will yield better performance? I guess `resourcedictionary` is the way to go if I'm using Blend for the UI design. – SimonSays Apr 10 '15 at 04:52
  • Sorry I just got the ability to comment, but I added an edit that was really meant as a comment. – thinklarge Apr 14 '15 at 15:46
0

It really depends on what you are trying to accomplish, if you are doing a custom control and want an accessable property, say for example you want a custom TextBox control with a Label on the left side and the Label text color is what you want to control with that Color property you would create a DependencyProperty which can also be set via a Style in the ResourceDictionary.

public class CustomTextBox : TextBox
{
    // Dependency Property
    public static readonly DependencyProperty LabelForegroundProperty = 
         DependencyProperty.Register(
             "CurrentTime",
             typeof(Color),
             typeof(CustomTextBox),
             new PropertyMetadata(Colors.Black));

    // .NET Property wrapper
    public Color LabelForeground
    {
        get { return (Color)GetValue(LabelForegroundProperty); }
       set { SetValue(LabelForegroundProperty, value); }
    }

    ...
}

Style:

<Style TargetType="CustomTextBox">
    <Setter Property="LabelForeground" Value="Green" />
</Style>

Even if you are doing something else, you should still prefer to define resources in a ResourceDictionary and try to access them as little as possible from the code behind (as it's easier to switch out the ResourceDictionary). But if you can elaborate on what exactly you want to do, I can give you a better answer.

Staeff
  • 4,994
  • 6
  • 34
  • 58
  • What I wanted are to have intellisense in xaml and codebehind, avoid hardcoding of the keys, and also looking at performance impact. – SimonSays Apr 10 '15 at 04:47