CODEWITHSUNDEEP
c#wpfoop
Click Ok
Click Ok

Reputation: 8852

Where initialize a specialized wpf control?

Let's say that I want create a specialized wpf control, "YellowTextBox". It will be the same of a common TextBox, but it will be... yellow!. Ok, I go to code:

public class YellowTextBox: TextBox
{
}

Now, the obvious part, I want it be yellow...

this.Background = Brushes.Yellow;

Where I put that line of code? In the constructor? In OnInitialized override? OnLoaded, etc...

There are some correct (or better) place to put that line of code?

EDIT:
I know I can do it via styles, my question is more an "OOP" way of do it, it can be any other kind of property or field, not exactly Background Color, that selected property was just an example :/

Upvotes: 2

Views: 2093

Answers (1)

15ee8f99-57ff-4f92-890c-b56153
15ee8f99-57ff-4f92-890c-b56153

Reputation: 37059

You really ought to initialize a specialized WPF control in the initializers for the dependency properties (for properties it introduces), and in the default Style (for the new properties, and for anything it inherits that needs a different default value).

But you want to do it in C#, for some reason.

In that case, we're talking about a) OOP theology, b) OOP reality, and C) WPF mechanics. In terms of all of those, do it in the constructor, and in WPF, in the constructor after InitializeComponent() (if applicable, not in your case) is called. That'll precede any styles that get applied to the control in WPF, and it's good OOP practice and theology to initialize everything in the constructor that you didn't initialize in field initializers. A new instance of a class should be ready to go, in a consistent state that won't throw any exceptions if you start using it. So that means the initialization should be all complete at that point. Never leave any initialization to anybody else. That's a booby trap.

Do read up on InitializeComponent(), but in your specific case, the constructor for a subclass of a standard control, you won't be calling it.

A control subclass in WPF will apply styles after the constructor. It must! Before the constructor executes, it doesn't exist. "After the constructor" is basically all there is, aside from the guts of the constructor itself. You can override OnApplyTemplate() to hook into things immediately after the template is applied. But that's much too late to be initializing much (with the exception of private fields which will refer to template children).

So if you initialize stuff in the constructor(s), it gets applied to every instance, and if it's a WPF control class (or any FrameworkElement subclass), consumers of your class can override it by applying a Style or a template later on. That's good WPF practice: You want to allow people maximum scope to customize your controls.

Upvotes: 7

Related Questions