I've been trying to interpret the XAML code in a project I've inherited and I want to figure out where some of the values are coming from in certain elements. When I look at an object's properties in the Properties panel, I can see squares next to each property. A white square indicates that the property value is the default, a black square indicates that the property value is "local" meaning it has been changed from the default and that change can be seen in the XAML tag, and a green square means "ambient."
There are styles applied to the objects so I can sort of intuit that the values in ambient properties must come from resource dictionaries. I'm still unsure where to look for the source of the values, which I want to do in order to change them. The documentation for ambient properties is hard for me to follow and doesn't answer all my questions, and I haven't found any documentation discussing the differences between default, local, and ambient.
If this is an appropriate place to ask, can someone explain and discuss the differences between default, local, and ambient?
Is there a word used to distinguish between these types of property values, i.e. is "default" a property value "type" or what?
And are there any property value types beyond those three?
My, what a charming profile you have. ;)
I just want to mention that you can get some information about the source of a dependency property's value using the static helper method DependencyPropertyHelper.GetValueSource(DependencyObject, DependencyProperty) in the System.Windows namespace.
"Default" essentially means that no source has been specified and so the value is taken from some built-in source. Note that some default values are dynamically generated and not constant. "Local" is when the value is explicitly set in that specific dependency object, overriding any values that it would otherwise inherit. "Ambient" is when the value is derived from some other source such as a style. I would refer to the distinction between these as different base value sources.
And yes, there are more than just those three. If you put the attribute TextBlock.FontFamily="Arial" in your Window tag for example, text blocks in that window will inherit that value from it. When you observe the property in the properties panel and roll over the box, it will say "Inherited." Note that the box is still green just like it is with "Ambient."
There is actually an enum that can help illuminate the various possible base value sources. It's called BaseValueSource.
Related
Basic Question
What I am trying (and failing) to do is pretty simple conceptually. I have an ArrayList of brushes as a resource, and I would like to bind an individual element's color to an element at a specific index in the ArrayList. If possible, I would like to get the index to bind to from the element's datacontext.
What it would look like is something like this:
<Line Stroke={DynamicResource DefaultGraphBrushes[0]}/>
I have tried a number of permutations of this (explicitly setting the ResourceKey, using quotes, '.', etc), and I am hardcoding the index for now to see if I can even do this. I would ideally like to get the index from the datacontext of the line.
Context
I am trying to do this because I have a graph control that takes in an arbitrary number of data sets and plots them on a grid. Some of the data sets have colors defined in the view model that they should always be shown in, some do not. For the ones that do I am simply binding to the color they provide and that works fine. For the ones that do not I need to pick a unique color from a predefined list of colors. The application has several different "themes" available, and the list of colors to use for the graph is different for each theme in order to make it readable and pretty. The brush the line is using needs to update when the user changes themes.
In the view model for each data set it knows whether it has an assigned color or not, and if it does not it picks the next index in the list of predefined colors to use to prevent multiple data sets from using the same color (unless we have more data sets than colors, which is unlikely).
I have been searching for a way to do this for quite a while. Any suggestions on how to make this approach work, or on other approaches that may work better are greatly appreciated. Thanks!
sometimes i don't understand why one should try too long to find a Xaml solution if this can be done much easier in code... Why not Bind your Stroke to a property that computes the Color ? code might access as well to resources (with TryfindResource or SetResourceReference). if you use tryfindresource, NotifyPropertyChanged if resource changed.
I've made a simple viewer of XAML documents that use a number of our own value converters, as well as built in ones, of course. It is expected behavior that there are DependencyProperty.UnsetValue bindings present.
I'm encountering a problem where the resulting view of my document acts like the built-in BooleanToVisibilityConverter is returning "Hidden" in that situation. I had expected it to act as if false was the value passed in. I was not even aware that "Hidden" was a possible result, and no such thing is mentioned in the MS docs.
Since I don't want to be changing the documents themselves to suit, I'm not planning to make a converter of my own that behaves as I expect. Any ideas out there to get what I want here, or even confirmation that what I'm seeing makes sense?
The BooleanToVisibilityConverter returns a Visibility. If you consult the documentation, you will find that Hidden is a valid value. A binding that results in DependencyProperty.UnsetValue will not attempt to convert this value via its associated converter. It effectively turns off the binding, i.e. it should have the same result as if the binding was not present at all.
In this case, your Hidden value will be coming from elsewhere. To understand the mechanism for determining a dependency property value, look at the documentation regarding dependency property precedence. In your case, it is most likely an inherited, or default value (but that is just a guess!)
I'm looking for a SL4 equivalent to .NET 4's SetCurrentValue API, which would appear to be exactly what I need for my scenario.
In short, I'm writing an attached behavior that updates the value of a given property at appropriate times. However, I don't want it to overwrite any bindings that are set on that dependency property. I merely want to push that value to the property (and therefore have any bindings refresh based on that value).
From what I can tell, there's no easy way to do this yet in SL4.
Thanks
Silverlight does not provide direct access to this level of dependency value. However its this level of value that Animations in storyboards set when they manipulate a property.
Hence a Storyboard with a 0 length duration containing a single DiscreteObjectKeyFrame might achieve your desired result.
I've managed to simulate what I'm after by detecting bindings and injecting a surrogate object between the source and target. I can then manipulate the surrogate and have both sides of the original binding refresh.
It's ugly and more work than I'd like, but it seems to work.
Kent
I am having a hard time figuring out good reasons for the dependency property. Why the System.Controls.TextBox "Text" property a dependency property and not a normal property? What benefits does it serve being a dependency property?
One of the things I am trying to accomplish is to add a ValidationRules property to my UserControl which will contain other validation rules. Like here:
<customControls:RequiredTextBox.ValidationRules>
<validators:NotNullOrEmptyValidationRule ErrorMessage="FirstName cannot be null or empty"/>
</customControls:RequiredTextBox.ValidationRules>
The problem is that I am not sure if ValidationRules property should be DependencyProperty or just a normal property.
The above code gives the following error:
{"Cannot add element to 'ValidationRules'; the property value is null. Error at object 'LearningWPF.ValidationRules.NotNullOrEmptyValidationRule' in markup file 'LearningWPF;component/addcustomerwindow.xaml' Line 35 Position 66."}
Here is the ValidationRules property:
public static readonly DependencyProperty ValidationRulesProperty =
DependencyProperty.Register("ValidationRules",
typeof (Collection<ValidationRule>), typeof (RequiredTextBox),
new FrameworkPropertyMetadata(null));
public Collection<ValidationRule> ValidationRules
{
get { return (Collection<ValidationRule>)GetValue(ValidationRulesProperty); }
set { SetValue(ValidationRulesProperty, value); }
}
The benefits are primarily two fold:
Firstly a dependency property is only created when it is used, this means the TextBox class can be very efficient, with a low memory footprint since it has a minimal number of real properties taking up space on the heap. This is especially important in WPF where all controls are just collections of more and more specific types. If each of those inner types declared tens of properties to define behaviour and look then a high level control like a button would end up having the size of a class with something in the ballpark of a hundred properties.
Secondly dependency properties can be tied to an object other than the type that they are created for. This allows the case where a control can set a Grid.Column property, which the Grid control can read and use for layout. This means that we don't hundreds of decorator classes supplying tiny pieces of functionality required by other controls. This means that xmal is far more intuitive and readable.
Edited to address the example in your revised question:
While your validation property won't gain much benefit from being a dependency property (basically out of the reasons in all the answers so far I can only really see my comment of memory footprint coming in to play), and it certainly isn't advantageous as it is in the case of the Text property of a text box where you may want to bind it, or change it based on some other input, I would still implement it as a dependency property. My reasoning for this is simple; you don't gain much, but it also doesn't cost you anything - I have never wished I had used a basic property in a custom control whereas when I first started writing them I was constantly upgrading my basic properties to dependencies because I wanted some extra functionality.
Simply put, while the dependency property is more complex to define that a normal property I would still use it as the de facto standard for WPF controls unless there was some good reason to do otherwise. In much the same way as a property is the standard for classes, even though a field is easier to implement.
The primary benefits I would say are:
First-class data binding support.
Clean Attached Property semantics
Property values which "depend".
That last point is key
Before Dependency Properties, having a value have a local value, an animatable value, an overridable value, a styleable value, a templatable value would require the declaration of multiple Properties/Fields/Dictionary entries, as well as complex state+precedence management.
Dependency Properties give you all these features out of the box, while declaring just ONE property.
That being said, in your case, you may not want to declare your ValidationRules as a DependencyProperty if you won't need to take advantage of these features.
If you do, you'll want to have different handling for your collections (non-empty collections for example). In this particular example, I would use Reflector and see how the .NET TextBox implements their validation collections, and see if you can reuse or copy the code.
There's no point re-inventing the wheel unless you're certain your wheel will be better. My personal experience is that my reinvented wheels tend to be missing things ;).
As Martin Harris already pointed out, DependencyProperties can limit the memory footprint by throwing the property values into a dictionary, however this can (and I believe was?) done by MSFT before the advent of DependencyProperties.
Martin also mentions Attached Properties, but those were also available (at least in designer) before the advent of DependencyProperties. The Attached Property implementation using DependencyProperties is much cleaner.
Dependency Properties are required if you want to use binding to populate the value of a property. If it was just a normal property, you wouldn't be able to bind the Text property to a property of your View Model object, for example.
We are using the standard method for our controls to report broken BO rules. This is done via the interface IDataError in our BO’s and in XAML the control is bound to the BO’s property etc. This approach works OK. But we need to show 2 types of visuals in the UI depending on the type (or category if you like) of the invalidation error. If it’s a required field then we show a CueBanner (water mark) but for other types we change the colour of the controls boarder. In both scenarios we set the tool type of the error message.
The Problem with IDataError is that it doesn’t support a method/property to distinguish between error types.
The only way I can do that is by examining the error text, required field text must contain the key word “required”. The following approach doesn’t feel right but it’s the only way I can determine the type of error and then deal with it accordingly. All required field rules must have as part of the error text “required field”.
To make this all work I have created a custom dependency property called ErrorMessage. In my ResourceDictionary I have a Style.Trigger for Validation.HasError. In there I set my dependency properties value to the ErrorContent. Now when my dependency properties value changes I can examine the text and set the Validation.SetErrorTemplate( myControl, newErrorTemplate) to the template to suit the error type. I have to wire up a few events to the control such as lost and got focus to manage removing or adding the cueBanner template but the whole thing will work. It’s just that I’m not sure it’s the best way to do it.
PS. When I set the ErrorTemplate i’m doing this in code, thats building and adding it. Is there a way to point Validation.SetErrorTemplate to a static resource keeping in mind that I need to switch between at least 2 types?
Your thoughts please..
Would it be possible to derive an interface IDataError that adds an extra property which is an enumeration of the error type. Then you could try and bind against it.
If you're okay with an (untested)approach that suffers a little bit of clarity, then you could do the following:
throw an exception instead of returning an string with the IDataErrorInfo Interface. In your ErrorTemplate, you can access the ValidationErrors (and the ValidationError.Exception Property).
Then, you use a DataTrigger on the Exception in combination with a converter, that checks for the right Exception-Type and return true or false. It should be enough to do the job.