I have a DataGrid and I need to apply an effect to a cell depending on the value of the cell.
Not sure how to do it. I have the effect writen in code but am not sure not to apply it. What i want to end up with is
myTextBlock.Effect = myDropShadowEffect;
How can i achieve this? Do I first say
If so, how do I define "MyEffect", should MyEffect be a c# class that implements a certain interface and overrides an "Effect" method or something like that?
You create an Effect by inheriting off of the Effect class or more likely the ShaderEffect class.
You can then create a new instance of your Effect class and assign it the Effect property of a control.
(Note if your effect is actually a Drop Shadow Effect there is already a builtin effect for that).
Have a look here
It seems it'll be easier to do in XAML. Unless you really need it in the code behind.
Related
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 :/
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.
I have a .NET PropertyGrid control which displays properties of some class. I want to change the color or font or background color(it doesn't matter just that they look different from the other displayed properties) of some property. I can do with writing custom editor but I was wondering:
If an easier method exists?
If I use custom editor then how do i change the editor of built-in types like bool, int etc?
No can do. The class that determines how an item is drawn is PropertyGridView. The source code is interesting, it almost made it:
private /*protected virtual*/ PropertyGridView CreateGridView(IServiceProvider sp) {
return new PropertyGridView(sp, this);
}
Nope, looks like at the last minute they decided against making the method overridable. The PropertyGridView class was also marked internal. Replacing all this code (there is a lot of it) is not a realistic option.
Creating your own UITypeEditor for built-in types is only possible by applying the [Editor] attribute to the properties in the class you want to edit. That's not a general solution. Consider creating your own form to make the object editable instead.
When I drag and drop a ToolTip object on my form in C#, every control on the form gets a new property called ToolTip which didn't exist before. I'm trying to create something just like ToolTip so that when I drag and drop it onto my form all of the controls will automatically get its new property.
I would also be grateful if anyone could give me a definition for this so that I can edit my question to convey my intention and meaning better.
What you are looking for is an "Extender Provider". Very simply, you don't actually add the new property to the controls' grids. You instead implement an interface that the VS designer looks for, that tells VS how to "transform" the property set in the grid to a call to the Extender Provider to really do the trick.
In addition to ToolTips, LayoutPanels like TableLayoutPanel and FlowLayoutPanel do similar things, as well as certain other "meta-window components".
ToolTip is an Extender Provider. The full documentation for implementing it is here, with a full example here.
ToolTip would likely be implemented like this:
[ProvideProperty("ToolTip", typeof(IComponent))]
class ToolTip : IExtenderProvider {...}
I have a .NET PropertyGrid control which displays properties of some class. I want to change the color or font or background color(it doesn't matter just that they look different from the other displayed properties) of some property. I can do with writing custom editor but I was wondering:
If an easier method exists?
If I use custom editor then how do i change the editor of built-in types like bool, int etc?
No can do. The class that determines how an item is drawn is PropertyGridView. The source code is interesting, it almost made it:
private /*protected virtual*/ PropertyGridView CreateGridView(IServiceProvider sp) {
return new PropertyGridView(sp, this);
}
Nope, looks like at the last minute they decided against making the method overridable. The PropertyGridView class was also marked internal. Replacing all this code (there is a lot of it) is not a realistic option.
Creating your own UITypeEditor for built-in types is only possible by applying the [Editor] attribute to the properties in the class you want to edit. That's not a general solution. Consider creating your own form to make the object editable instead.
I want all labels inside a detail view to be bold. I created a simple custom label control that forces the font to be bold. This has the feeling of code smell to me. I'm not concerned with a developer being able to customize the custom control (baseDetailLabel). I just want to enforce an application wide standard for detail labels (They must be bold). Is it appropriate to force the font style when the control is initialized or should I be doing this in another method? I do want the style visible from the designer.
public class BaseDetailLabel : System.Windows.Forms.Label
{
public BaseDetailLabel()
{
System.Drawing.Font f = new Font(this.Font,FontStyle.Bold);
this.Font = f;
}
}
From the description I take it that you also have Labels that you don't want to be bold. In that case a separate Control class seems the best way to go.
The simple constructor approach will not prevent override, just sets an initial value. I think that is what you want. To force Bold you would have to override the OnPaint method.
About the smell: it isn't fancy but that comes with the territory. You're enforcing a style rule where there are no good (better) ways of attack. Unless you want to build an entire Style system.
This should be fine. However, I might caution you that you'll probably need to dispose the font somewhere. Fonts are graphical objects which need to be disposed - and I'm not sure if destruction of the label would automatically do that for you.