In Expression Blend 4 the Simple Styles use the following XML namespace:
http://schemas.microsoft.com/expression/interactivedesigner/2006
It frequently uses an attribute from this namespace called IsControlPart which is a boolean. I've googled extensively and can't find any actual documentation on this attribute.
I think I figured it out.
When WPF creates the default templates for its controls, it names some of the elements with the prefix "PART". For example, with a Slider control, it has two parts, PART_Track and PART_SelectionRange. This in itself has nothing to do with Expression Blend.
These parts necessary for the basic functionality of the control. Most simple controls, like a Button, do not have any parts, so they can be fully customized without having any restrictions.
More complex controls rely on parts being present in order for the code-behind to work properly. It doesn't care what the control looks like, or where they are in the visual tree, so long as they exist and are of the right type.
In Expression Blend, there is a "Parts" window which is by default a tab alongside the "Project" and "Assets" tabs. When you are editing a template for a Control, if there are any parts defined for that control it lists them in this Parts window. It shows a check mark if that part exists in the current template, and if not you can double click on it and Blend will create the element for you.
I am still not sure exactly how the d:IsControlPart attribute works. I tried making my own custom Control and creating a element with the IsControlPart tag, and then creating a template for that control to see if it would list the part. It didn't. So this is still not 100% answered.
Related
I have made a FormBase, from which I inherit a FomBaseList and a FormBaseDetail.
All other forms in the project are derived from FormBaseList or FormBaseDetail.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs with the value found in FormBaseList.Designer.cs.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
I'm new to WPF and tyring to uderstand the best way I can modify any given control attributes. What I was trying to achieve is to show tooltip for a cell. Yes a quick google and can see xaml of how to do it. But I want to understand how can one learn to figure out this out using some tool.
I came across Snoop that can show visual tree of a control very easily (CTRL+SHIFT Mouse over). What I'm trying to understand is if one knows of visual tree, how can one change it? For example, let's say I use WPF DataGrid and bind it to a source and display column using DataGridTextColumn.
<DataGridTextColumn Header="First Name" Binding="{Binding FirstName}">
Now let's say I want to show tooltip for each cell. So I fire up Snoop and CTRL+SHIFT mouse over the cell. Snoop shows me that its a DataGridCell that is using Border and withing it ContentPresenter which ends up using TextBlock to show the value. So that means that if I can somehow access that textblock, I can set its tooltip property using binding. Issue is that I don't know how I can access it in xaml.
In other words, knowing a visual tree, how can one access it in xaml for any given control. This will also be very handly for 3rd party controls.
Thanks
Your'e asking quite a bit here, and i'm not sure I completely understand your intention, so I hope I got this right. Your'e asking if you can access the complete visual representation of each control and change it using xaml. The answer to that is yes, but you shouldn't.
I'll get to what I mean in a bit, but first I'd like to clarify some concepts, since i'm not sure you're using them correctly.
XAML:
Xaml is the declarative markup representation of your views and nothing more. Xaml syntax directly corresponds to it's respective classes and their properties. Xaml maps tags to classes and attributes to properties. It's a small distinction, but it's important to think this way. Everything you can do in xaml you can also do in code (although it would often be much more work). Again: xaml refers to markup code only.
<ClassA PropertyA="Value">
<ClassA.PropertyB>
<ClassB />
</ClassA.PropertyB>
Default property value
</ClassA>
Logical tree:
The logical tree is the runtime representation of your xaml code. it consists (mostly) of the controls you set in your xaml files.
Visual tree:
The visual tree is the visual representation the logical tree. It contains much more since it contains the concrete visual representation of everything displayed in your view. Most of the logical tree can't be directly displayed. WPF uses Data and Control Templates together with Styles to determine exactly how each object is supposed to look. In case of data templates that can also mean simple data objects and not only WPF controls.
Now for your question: so can you access the concrete visual representation of each control?
Yes, but you'll have to use control templates to manipulate it's visuals. Also, control templates are usually applied to control types and not specific controls, so you'll have to deal with that as well.
And that's why you shouldn't access it. The xaml representation usually gives you all you need to modify your control, and even if you do use templates you shouldn't change every last piece of it. Templates are used to style a control, so only write enough to show it as you wish. There's no need specify everything.
However you can access the entire visual tree more easily using procedural code, if you use the VisualTreeHelper class (that's how snoop does it, by the way). Using it you can traverse the visual tree and access all it's classes and members. If you really want to access every single visual object you'll do it much more easily with the VisualTreeHelper.
I am very new to Expression Blend but can't find any solution with google. I would like to style a Menu and it's items. But how can I see the actual look of the PART_Popup? The IsOpen Property is bound to something like {Binding IsSubmenuOpen, RelativeSource={RelativeSource TemplatedParent}}. It seems I am only looking at something complete invisible :). There is also a SystemDropShadowChrome but I actually can't see this thing. The eyes next to all the items are active. And even if I change some background colors all that I see is just a black transparent rectangle.
Is this a toolkit control (dropdownmenu) or a telerik (radmenu) or something? If you've already broken out the template (eg; Right click->Edit Template->Edit Current/Copy) Then there's a couple things you want to try to find it since sometimes they can be oddly embedded.
Go to the root level of the control, try Right Click->Edit Additional Templates->...
If that' doesn't provide your part_ look in your broken out template resource you've created and inspect your object tree. You're looking for embedded controls appearing as objects. Right click the embedded control in your object tree and edit its template (Current or Copy)
You'll potentially sometimes have to drill down multiple layers within a template to expose the objects you wish you to edit. If you specify which control you're working with I'm sure we can tell you exactly how to get to where you need more efficiently. Cheers!
Try exploring the States tab. Most likely some of the parts are only visible in certain states.
I wanted to know which one amongst Style and UserControl would be better to use in WPF?
For example:
I have created an image button in two different ways.
One uses Style and ContentTemplate property is set.
It uses one other class with dependency properties.
The other way is I have created a UserControl which has a button and its content property is set.
The file UserControl.xaml.cs also contains the dependency properties.
For Code details see the answers of this question:
Custom button template in WPF
Which one would be better to use? In which scenario should one go for Style or UserControl or any CustomControl?
Styles are limited to setting default properties on XAML elements. For example, when I set the BorderBrush , I can specify the brush but not the width of the border. For complete freedom of a control’s appearance, use templates. To do this, create a style and specify the Template property.
Styles and templates still only allow you to change the appearance of a control. To add behavior and other features, you’ll need to create a custom control.
For example,
To create a button like a play button use styles and templates, but to create a a play button which will change its appearance after pausing it use UserControl.
For this type of thing I would go with Style, even though I'm not really adept with graphical tools. I tend to produce a basic, boring style that I can get started with and then prettify it once the application functionality has been verified.
The nicest thing about WPF is being able to distance much of the graphical look, feel and behaviour away from the code.
This allows you to change the style of your application without revisiting the code and indeed means that you can change styles on the fly at runtime.
There is an awkward line to tread with regards to how much behaviour is placed within the XAML and how much is placed within the code. A rough guide would be to decide on what behaviour must always be present within the UI and place that in the code, everything else place within the XAML.
Think of the code as being an abstract class with defined interfaces and the XAML Styles as being classes based on that class and you'll get an idea of what I mean.
Conversely, I know that people who are far more adept at the GUI work prefer to put more functionality in the XAML and others who prefer the code side, because they find the GUI work slow or difficult.
When thought of that way you'll see that there's never really a right or wrong answer, just better solutions that suit your skills.
I'm just getting my feet wet in Silverlight, and don't really understand the differences and pros/cons of creating a UserControl vs. creating a Control for the same task (as in when you right click on a selection in Expression Blend, for instance).
It seems like selecting "Make Into Control" just creates a new template for the base type you specify, whereas creating a UserControl creates a whole new base class. Is that correct?
In this particular instance, I'm creating a custom text box control that only takes numbers, and divides itself into 3 sections, storing 3 values into separate properties as pictured below. In this particular case, which would be best?
UserControls are meant to be a composite control - basically a bunch of other "controls" grouped together to work as a single, cohesive unit.
Custom Controls, on the other hand, are intended to be used as a single control. Think of the basic controls in the framework, such as TextBox or Button - if you were implementing something like that, you'd want a Control. (This is less common than UserControls, especially in WPF, since you can use templating on base class controls to accomplish quite a few things where you'd need custom controls in other frameworks). A custom Control is all about defining new behavior for a single "control."
If you consider your control to be a group of three text boxes then a UserControl would be appropriate, but if your control will still essentially be a TextBox then you should extend the existing control with "Make into control."
It sounds like you need a UserControl to me.
Dov, I think you've answered your own question with your update. Custom Controls are most useful when you want to make a control that supports templating. Otherwise they are useful when you are inheriting from other controls to cleanly add functionality (TextBox -> PasswordTextBox).