I don't understand the interest of a dependency property without callback defined.
A callback is just an added convenience -- dependency properties are integrated into the framework runtime, and have a built-in callback mechanism that updates any bindings. That is, if you set a binding with a dependency property as the source, then the target will update automatically when the dependency property changes.
For example, let's say you have a custom control with a DP defined:
public string SomeDP
{
get { return (string)GetValue(SomeDPProperty); }
set { SetValue(SomeDPProperty, value); }
}
public static readonly DependencyProperty SomeDPProperty =
DependencyProperty.Register("SomeDP", typeof(string), typeof(SomeFrameworkElement), new PropertyMetadata(null));
And if you set up a binding with the DP as the source for a TextBlock's "Text" property:
<local:SomeFrameworkElement x:Name="someFrameworkElement" SomeDP="initial" />
<TextBlock Text="{Binding ElementName=someFrameworkElement,Path=SomeDP}" />
Then whenever "someFrameworkElement"'s "SomeDP" property changes, the text will also change.
Related
I'm very new to WPF and while studying (particularly creating a user control), I stumbled upon this thing called "DependencyProperty".
I understand how it works in code but why and when do we need it when I can just create a property and expose it for public use.
Example:
XAML:
<UserControl.....>
<StackPanel Orientation="Vertical">
<TextBlock x:Name="label" Text="Hello"/>
<TextBlock x:Name="text" Text="World!" />
</StackPanel>
</UserControl>
CS file:
public partial SampleUserCtrl : UserControl
{
public string LabelText { get { return this.label.Text; } set { this.label.Text = value; } }
public string TextBoxText { get { return this.text.Text; } set { this.text.Text = value; } }
}
DependecyProperty in WPF has different uses.
Advantages compared to normal .NET property
Reduced memory footprint It's a huge dissipation to store a field for
each property when you think that over 90% of the properties of a UI
control typically stay at its initial values. Dependency properties
solve these problems by only store modified properties in the
instance. The default values are stored once within the dependency
property.
Value inheritance When you access a dependency property the value is
resolved by using a value resolution strategy. If no local value is
set, the dependency property navigates up the logical tree until it
finds a value. When you set the FontSize on the root element it
applies to all textblocks below except you override the value.
Change notification Dependency properties have a built-in change
notification mechanism. By registering a callback in the property
metadata you get notified, when the value of the property has been
changed. This is also used by the databinding.
As you dig deeper to WPF you will also stumble upon DataBinding and object-oriented design patterns like MVVM or MVPVM. Both patterns rely on DataBinding which is achieved through using of Dependency Properties. You cannot perform data binding if it is not a dependency property.
Basically data binding through dependency properties allow the user to update the view when updating a value through code.
Ex: In Windows Forms in order to update a label text you assign its value on the code behind like this:
lbl1.Text = "foo";
In data binding where as you bind in the XAML (View)
<label Text = "{Binding foo}"></label>
and update the values in your code behind:
foo = "foo";
I am not an expert myself so sorry if I might sound confusing.
Dependency property has many benefits over normal property.
A dependency property value can be set by referencing a resource
It can reference a value through data binding
It can be animated. When an animation is
applied and is running, the animated value operates at a higher
precedence than any value (such as a local value) that the property
otherwise has.
You can learn more about it from msdn.
The main advantage of DP property you can find anything in DP like your Control info and you current DataContext info.
public string MyProperty
{
get { return (string)GetValue(MyPropertyProperty); }
set { SetValue(MyPropertyProperty, value); }
}
// Using a DependencyProperty as the backing store for MyProperty. This enables animation, styling, binding, etc...
public static readonly DependencyProperty MyPropertyProperty =
DependencyProperty.Register("MyProperty", typeof(string), typeof(MyUserControl), new PropertyMetadata(null, (s, e) => OnChangedValue(s, e)));
private static void OnChangedValue(DependencyObject s, DependencyPropertyChangedEventArgs e)
{
throw new NotImplementedException();
}
I have a custom WPF usercontrol which has a dependency property (snippet below). Which is not firing it's PropertyChangedCallback correctly.
CustomControl:
public static readonly DependencyProperty ValueProperty =
DependencyProperty.Register(
"Value", typeof(float?), typeof(CustomControl),
new UIPropertyMetadata(new PropertyChangedCallback(OnDependencyPropertyChanged)));
public float? Value
{
get { return (float?)GetValue(ValueProperty); }
set { SetValue(ValueProperty, value); }
}
private static void OnDependencyPropertyChanged(object sender, DependencyPropertyChangedEventArgs e)
{
// Do something
}
When I bind to the property with a simple path, all is fine. However when I use the delimited path syntax, the dependency property is not updated when it should be.
Working binding:
<namespace:CustomControl Value={Binding ViewModelProperty}/>
Not working binding:
<namespace:CustomControl Value={Binding ViewModelProperty.ObjectProperty}/>
With the working syntax, the OnDependencyPropertyChanged event handler is called in response to PropertyChanged events for ViewModelProperty fired by the view model. However with the 2nd syntax the OnDependencyPropertyChanged event handler is only called for changes to ObjectProperty, and is not called for changes to ViewModelProperty. Do I need to do any additional setup to make the delimited (.) path syntax work appropriately? (Have the same behavior that properties like TextBox.Text have by default)
Have you tried your binding with the Path attribute?
<nmspc:CustomControl Value="{Binding Path=ViewModelProperty.ObjectProperty}" />
I recall that when building a two-way binding programatically the Path attribute is required.
I've bound the visibility of some buttons to a bool, but when the bool changes, the button's visibility does not change. Why could this be?
The boolean is set up as such:
public static readonly DependencyProperty editModeToggle = DependencyProperty.Register("editMode", typeof(bool), typeof(Window));
public bool EditMode
{
get { return(bool)GetValue(editModeToggle); }
set { SetValue(editModeToggle, value); }
}
I'm pretty sure the binding isn't at fault.
[Note: I have set up a Converter that works and the binding works. The visibility just doesn't change when I change from true to false or vice versa]
Binding:
<Button Content="Test" Visibility="{Binding ElementName=mainWindow, Path=EditMode, Converter={StaticResource BooltoVisibilityConverter}/>
There are a few things you need to check when a binding does not work as expected:
Does the bool property notify change using
INotifyPropertyChanged?
Do you use a converter to convert from
bool to Visibility?
Do you see any binding errors in output
window?
Have you tried putting a breakpoint on binding in xaml
or setter in bool property?
As you have mentioned in your comment, you have not implemented INotifyPropertyChanged interface.
The need to implement the interface is whenever value of the property in ViewModel changes, there has be be a way for binding to know that. So, after implementing INotifyPropertyChanged, for each property, you raise the PropertyChanged event with the property name in it. That way, the binding knows that value of the property has changed.
There are lots of articles online. Here is one to get you started: INotifyPropertyChanged and WPF
Dependency Property registration is not correct -
public static readonly DependencyProperty editModeToggle =
DependencyProperty.Register("editMode", typeof(bool), typeof(Window));
It should be-
public static readonly DependencyProperty editModeToggle =
DependencyProperty.Register("EditMode", typeof(bool), typeof(Window));
Notice the spelling of property - 'E' should be capital since its case sensitive and your property name is EditMode not editMode.
In this case you don't need point 1 from decyclone list since you are using a dependency property. I think that you should add Mode=TwoWay in binding if you don't have it, that will solve it.
We can achieve the binding by simply CLR property, so why do we need to use DP?
When do you need DPs over CLRPs?
When you need binding
when you need property value change callback (Default Implementation)
When you need property value validation
When you need animation
When you need property value inheritance
When you need to attach a property value to another element (Attached Property, but still)
When you need styling
Some of these can be implemented in CLR properties. But, with DPs, its piece of cake.
Typically these are declared in UserControls and derived controls.
You can bind to a CLR property, but you can't bind with a CLR property; you'll need a dependency property to do any binding.
Edit (in response to comment)
Let's say you need a TextBox, but you want to customize it to have different behaviour in "EditMode" and "ReadMode". You'll need to either create a derived class or a UserControl; in either case you'll add a DependencyPropery.
public class TextBoxWithModes : TextBox
{
public bool EditMode
{
get { return (bool) GetValue(EditModeProperty); }
set { SetValue(EditModeProperty, value); }
}
public static readonly DependencyProperty EditModeProperty = DependencyProperty.Register(
"EditMode", typeof (bool), typeof (TextBoxWithModes));
}
With this in place, you can declare it in XAML:
<Namespace:TextBoxWithModes Text="enter text here"
Width="200"
HorizontalAlignment="Center"
EditMode="{Binding IsChecked, ElementName=editModeCheckBox}" />
I have this DependencyProperty:
public bool ShowEntireHierarchyEx
{
get { return (bool)GetValue(ShowEntireHierarchyExProperty); }
set { SetValue(ShowEntireHierarchyExProperty, value); }
}
public static readonly DependencyProperty ShowEntireHierarchyExProperty =
DependencyProperty.Register("ShowEntireHierarchyEx", typeof(bool), typeof(CustomizeStatisticsStyleControl), new UIPropertyMetadata(false));
And I'm binding it to this CheckBox in XAML:
<CheckBox Margin="16,5,0,0" x:Name="checkBoxHierarcy"
IsChecked="{Binding ElementName=customizeStatisticsStyle, Path=ShowEntireHierarchyEx, Mode=TwoWay}">
S_how entire gate hierarchy
</CheckBox>
But for some reason the CheckBox does not change the ShowEntireHierarchy property, but if the ShowEntireHierarchy property changes in code, the CheckBox does change. What am I missing here?
Thanks!
The reason SetValue is not being called is that dependency property bindings do NOT go through the CLR setter. A bound DP is updated "behind the scenes" by WPF, i.e. directly in a private "slot" managed by the DP system.
It's therefore probable that your DP is being set when the check box changes. The setter breakpoint not being hit shouldn't concern you. You should only worry if you have some other reason to believe that the DP is not being updated.
To break on changes in a bound DP, add a PropertyChangedCallback in your property metadata, and set a breakpoint in that callback.