The States pane in Blend 4 does not appear to show the VisualStates declared on a UserControl using the TemplateVisualState attribute. Is this to be expected and if so why? Creating the States manually in Blend seems to work correctly.
User controls aren't typically designed to be modified or re-templated the same way that regular controls are.
Most of the time where you want a control to be editable and offer alternative animations (through the states panel for instance) you're going to want to build something that derives from a proper custom control type.
Related
I am working on new WPF/MVVM project, where I see all most all controls are written for different needs, right from textbox to treeview. All are rewritten for simple need, for example, grid,stackpanel control are rewritten to add space between each item and textbox is rewritten to include label for it so that it has both label and text input are on itself.
My question : Is there any serious issue we would encounter because of this customization?
Already, I am seeing issues with aligning all controls, will i would see any more issues because of this?.
You should never create a custom or user control to add margins, a label to a TextBox, or a new ItemTemplate to a ListBox.
UserControls are for grouping frequently used combinations of controls into one reuseable control. An example may be a custom List-of-Values control that opens a dialog. This would be fine to implement as a UserControl.
Custom controls are good when a native control does not suit your needs. Say that you want to reimplement a DateTimePicker from scratch because the native one doesn't include milliseconds.
There are no serious issues as such, but you may find yourself maintaining all these controls for the next many years without there being a need to do so.
Settings Margins should be done in the View where you are using it, or on a Style in a ResourceDictionary.
This is of course only my opinion (and that of many others, I except), but if you find that the majority of your controls are 'customized' this way, you are doing it wrong.
Style and Templates rather than UserControls and custom controls.
The main issue is that you lose the ability to alter margins only in a single view. If you change your custom controls' inner paddings and margins, you will be changing all the views in your solution. If you use a style, you can always override it by defining a new style in the view, or by setting the property directly.
So much reading, and so much about inheritance, I can't find any direct answers, so here goes.
If you have a base-class derived to do certain things, look or act a certain way, you can subclass it and get all the functionality of the parent class with only slightly modified differential. The same does not appear to be the same for working with WPF Themes... more specifically, the combobox control (similar issues with textbox, but that's obviously less complex).
By looking at the Control Template Examples, they discuss the entire structure of it, the borders, backgrounds, glyphs, actions, properties, etc.
If the ONLY thing I want to do with a combobox is to change the border of it to Red if there is an error in it, it appears, I have to basically redefine the entire thing and somehow put in my custom trigger setting / color to be implemented.
Somewhat similar is that of the textbox control and how its created. It has the named control when trying to nuts around with the background color... you can't just say... background = some static brush value.
What shortcuts are out there to only allow overriding these small elements without having to re-create the entire template control. I can just imagine what would go on with grids, tabbed controls, and others that could get extremely messed up if you miss one simple thing.
I also see that some controls are made up of OTHER Control.Templates, so how might I be able to attach to changing the property setting on just the single element of the control template... Such as the combobox has the control template for the Toggle Button. From that, it has a border via x:Name="Border" and I want to change THAT element within a derived style.
Thanks
I might not understand your question here. But from what i get is:
Yes you can't partially implement Templates, in fact i wouldn't know how this could be possible. But, if you want to change certain things, you can of course do that. You can create Styles, Templates, Brushes etc. as DependencyProperties and use TemplateBinding to bind to them, on the given child control.
Remember that WPF allows always to change the template on the fly. if we could partially change the template this would might hurt performance or could get messy and complicated. Still, you can do that using ContentControls and TemplateBinding or simply Triggers.
For my custom controls, which might contain multiple part sub controls, i usually add a style for them. For example, a custom ComboBox would contain a ToggleButtonStyle.
One thing that would be nice though, would be to add control template triggers without the need to reimplement the template.
I just want to wrap a standard control with some more additional properties (look stay the same, I don't want to do theming in first stage).
Can I just inherit from this standard control instead of UserControl or Control ? In fact I read it is obligatoryb to use Custom Control Project Template and not UserControl ontrol Project Template. Why ?
Update: I try with a Custom Control Project and inherit from the standard slider but I have nothing show up visually ! Now what should I do to have the same visual slider as the standard one ?
I know the difference between a user control and a custom control but in practice how do you do when you just want ONE single standard control ? How will a slider for example resize AUTOMATICALLY if I encapsulate it inside a User Control instead of a Custom Control ?
A custom control is a single control and can derive from another control, this would support styling. A UserControl is a composite control out of many different controls, and as a whole, doesn't support styling (the parts do however).
If you want to add features of any kind to an existing control, derive from it. If you want to pack several controls together to make it easier to handle them (you could still add DP's to it), use a UserControl.
A custom control alone won't do anything related to resizing etc, that is dependent on the settings you supply to it from the outside (ie. HorizontalAlignment, VerticalAlignment and others) when you used it in a container. The custom control should inherit the default template from the base class unless you override it.
I'd like to know what the differences between an Style (for a control) and a control template are.
Best regards,
Gonzalo
A style controls the individual properties of a control. For instance, a button style can say, "For every button, use this background." A style is changing a single property on a control.
A control template is actually handling how the control displays its bound data. Instead of saying, "I want to override a control's properties," you are assembling together other smaller controls into a single control that can present different views of the bound data.
Previously in WinForms, if you wanted to write a custom list box (say that had an icon next to each item), you had to inherit from the ListView control and override the painting methods. This involved a ton of experimentation - huge pain. With WPF templates, you can use XAML to construct smaller controls together and bind them to different properties of the parent control. You are actually defining the Visual Tree for the control.
See this article for an in-depth explanation by Charles Petzold.
Imagine your control is a house.
A Style is conceptually similar to putting down a new carpet and painting the walls. The house itself is still the same but its outward appearance is different.
A ControlTemplate is the equivalent of knocking down a wall or adding a conservatory. The actual structure of the house has changed.
Use a Style when you want to change the outward appearance of the control E.G. it's background colour or the thickness of it's border.
Use a ControlTemplate when you need to change the underlying structure of the control. This is useful when you want to change the layout of certain aspects of a control. A good example is in this article which re-templates a TabControl to look like the navigator from Microsoft Outlook.
I have started writing some custom controls for a highly visual project. I was wondering what are your 'best practices' when coding WPF custom controls?
If you want your custom control to support direct content like this:
<CustomObject>
Direct content example 1
</CustomObject>
<!-- or -->
<CustomObject>
<Button Content="Direct content example 2" />
</CustomObject>
Then you need to use the ContentPropertyAttribute which tells WPF which property is actually being set when you write xaml like this.
The attribute can be used like this:
[ContentProperty("NameOfProperty")]
public class CustomObject
{
[...]
ContentControl uses this attribute to set the Content property but note that the property can be called anything; the WPF TextBox, for example uses this attribute to set the Text property.
E.G.
[ContentProperty("Text")]
The property also does not have to be a dependency property (see the MSDN documentation example for evidence of this).
Finally, this attribute is specific to the xaml parser and not to ContentControl and can be used with any type which can be seen from the TextBox example above (TextBox does not derive from ContentControl).
Keep property names the same as the property names for built-in Controls if you can do so without changing their meaning.
e.g. if you have a CustomerDisplayer custom control don't call the list of customers Customers, call it ItemsSource.
It might seem counter intuitive at first but it saves a lot of headache in the long run because future programmers can make a lot of assumptions about how a property called ItemsSource will act that they can't necessarily make about a Customers property.
Make sure the control can be re-styled and re-templated without changing the way the control operates. Don't make the control assume that the Listbox and Button are both within the same panel or that there even is a Listbox or Button. Check out the MSDN article on control authoring for some recommendations on how to do this.
Some content controls are dependant on the existence of other controls in their ControlTemplate. Typically this should be documented using the TemplatePart attribute.
The Combobox control, for example, is dependant on the existence of a TextBox and a Popup controls in its template.
This would be documented by placing the attribute on the class like so:
[TemplatePart(name="PART_EditableTextBox", type=typeof(TextBox))]
[TemplatePart(name="PART_Popup", type=typeof(Popup))]
public class Combobox : Selector
{
[...]
The naming convention is "PART_controlIdentifier".
The relevant items would then be given the same names in the control template so that they can be located in the OnApplyTemplate method.
This then allows the control to hook up to events, set properties and call methods on the controls contained in the template.
This attribute is for documentation purposes so that people designing custom control templates (and tools such as Expression Blend) know that the control is dependant on the existence of another.
Learn how to use both dependency properties and routed events (and how they work) so that you can use them effectively in your own control.
Both of these types provide services for integrating your control with the systems built into WPF.
By using these two features in your custom controls you will get the following advantages:
Dependency Properties provide support for databinding, animations and can be used in styles.
Routed Events can be propogated through the visual tree which means that other elements can handle the events.