Dependency Properties on Controls - wpf

In WPF some properties of controls are dependency properties, others are normal properties.
Eg TextBox.SelectedText is a normal property and not a dependency property. I use MVVM and it happens often to me that I want to bind to some property, but I cant, because it is a normal property.
Can someone explain to me, what logic stands behind the decision whether a property is normal or a dependency property.
Also, can I work around this and somehow bind to the normal properties as if they were dependency properties?

Go through these links
When to use a WPF Dependency Property versus INotifyPropertyChanged
http://social.msdn.microsoft.com/forums/en-US/wpf/thread/65bf126f-e706-4d3e-8cc3-e0130a0ee6de
http://joshsmithonwpf.wordpress.com/2007/06/22/overview-of-dependency-properties-in-wpf/
WPF: What distinguishes a Dependency Property from a regular CLR Property?
How to set bindings on CLR Properties using DataResource
You will get better idea about what you are looking to find out

You can bind to normal properties, but if your property changes, your binding will not get notified. However, you can implement INotifyPropertyChanged in your classes and the binding will update your control automatically.

Related

Is dependency property same as a CLR property which emits a PropertyChanged event as callback?

The question is related to WPF Data Binding and MVVM pattern.
I am bit confused now distinguishing between the Dependency property defined in the XAML.cs file as well as a CLR property defined in the view model which is bound to some property of a component
For example say, I have a textbox in MyPage.xaml. So I created a dependency property to bind the textbox text property in the MyPage.xaml.cs maybe some String. The next time, I created a viewModel MyPageViewModel.cs which implements the INotifyPropertyChanged interface and
created a CLR property there(String), which emits an event PropertyChanged when it changes or the property is set with a new value. So are these both the same? Is there any difference?
I have 3 questions
Is the Dependency Property same as CLR property which emits a PropertyChanged event when it changes?
Whether Dependency property is written in the view itself(MyPage.xaml.cs) or can it be included in the view
model(MyPageViewModel.cs)?
In MVVM pattern, we use the CLR properties more which emits an event during property change. So can dependency property be replaced
by such kind of CLR properties?
Thanks in advance.
An dependency property is on a DependencyObject from which all WPF UI elements derive from (and only works there), as it's static and saves it's value in a kind of collection assigned to a specific DependencyObject (on which the dependency property is defined). Dependency properties can be defined in a class outside of the actual DependencyObject to extend it's functionality without modifying the original user control class.
When you write a user control and want a ViewModel to allow to bind a value and receive notifications when it's changed, then you create a dependency property.
Imagine it like an USB cable, where you have a male plug and a female receptacle. The CLR property is like the plug and the dependency property is like the receptacle.
A dependency property allows you to store that's associated with a control but isn't part of the instance. As you can see on the MSDN Examples
public static readonly DependencyProperty IsSpinningProperty =
DependencyProperty.Register(
"IsSpinning", typeof(Boolean),
...
);
public bool IsSpinning
{
get { return (bool)GetValue(IsSpinningProperty); }
set { SetValue(IsSpinningProperty, value); }
}
the dependency property is static and GetValue and SetValue are methods of DependencyObject (base class on which all WPF UI elements are based on).
Depencency Properties (and attached properties/attached behavior) can also be used to extend the functionality of a UserControl without inheriting from the actual user control type, i.e. notifying the ViewModel when a certain value changes which is not provided by the original user control.
Is the Dependency Property same as CLR property which emits a PropertyChanged event when it changes?
No, it's not the same. They are both 2 sides of the databinding engine. A DP is defined on the view to allow a view model to bind a INPC Property (Property that rises PropertyChanged event)
Whether Dependency property is written in the view itself(MyPage.xaml.cs) or can it be included in the view model(MyPageViewModel.cs)?
DP are part of the View-Layer as they depend on DependencyObject, which is part of the WPF framework and hence view concern. While technically nothing prevents you from using them in the ViewModel, this causes a tight coupling of your ViewModel towards a certain View technology, so it doesn't fully comply MVVM pattern.
Be aware though that unit testing Dependency Properties may be quite difficult as they don't store the values on the class they are defined on but in some kind of dictionary where the GetValue/SetValue methods warp around.
Last but not least, since DependencyObject is the base class of all UI it is as well as most of the classes that derive from it thread affine, which means you can only access it from the thread you created which may cause you much pain in both unit test (especially if the tests run in parallel like MSTest used to do. Dunno if its still true as of today) and in your code.
In MVVM pattern, we use the CLR properties more which emits an event during property change. So can dependency property be replaced by such kind of CLR properties?
In ViewModels you could and you should use INotifyPropertyChanged. If you are developing a user control, you shouldn't replace DPs with "CLR" properties, because this makes the property not work with databinding in XAML.
If your UI elements should expose a property which can be used with data binding you have to use dependency properties (or attached properties which are pretty similar, but you place attached properties on i.e. the child elements. Grid.Row and Grid.Column are examples of attached properties).

How can I use two way bindings with dependency properties?

I read that I need to implement InotifyPropertyChanged but I can't have my control inherit from two different classes.
I'm a little confused as to how I do this.
Basically I wish to have a parent control have a property bound to a control in the UI (already done).
and then I wish to bind that value to a property in a child FrameworkElement.
however, the usercontrol is already inheriting from usercontrol, and multiple inheritance is not supported. How do i go about alerting other dependencyproperties that my dependency property has changed?
INotifyPropertyChanged is not a class. It is an interface, and C# allows you to inherit from as many interfaces as you'd like.
If that doesn't clear up your issue, please add more details. An example would be great.

Can I have a MVVM model inherited from an other model?

I have a ProductViewModel class which contains different properties.
Then I have a ProductDetailsViewModel class which inherit from ProducViewModel class. The reason I am doing it this way is in order to get correct binding environement and avoid duplication of properties from previous view.
I am allowed to do this or each ViewModel should be clearly isolated?
Through code I can acess the properties of the ProductViewModel class from ProductDetailsViewModel view but when I set the datacontext of my ProductDetailView to ProducDetailsViewModel class and bind properties URI for instance which is define inside the inherited class, binding seems not occurs.
Any idea ?
You can do this too, but i think maybe better would be to separate them and use Dependency Injection.
You create and interface for your ProductViewModel and implement it and then you inject this into your ProductDetailsViewModel.
MVVM + WPF + DI
MSDN DI
Yes this is fine, and I do this all the time in my WPF projects so it should just work. Some suggestions:
Can you check your output window when debugging the application. Are there any binding errors suggesting a mis-typed xaml binding?
Are you using any DataTemplates in xaml which bind to a specific type, e.g. ProductViewModel not ProductDetailsViewModel?
Does the base type (ProductViewModel) implement INotifyPropertyChanged?
Are all the properties in ProductViewModel and ProductSetailsViewModel raising the PropertyChanged event with directly typed string property name?
Best regards,

How to create a dependency property in Silverlight using MVVM?

let say there is a textbox and i want to control the visibility of this control using MVVM, is there a sample on how to do this? First create a dependency property then get it hooked up in the ViewModel. Thanks.
Typically, you wouldn't need to use a dependency property in this case. Dependency properties really only need to be implemented for things like controls themselves, not for determining behavior. Behavior, such as the visibility of an element, can be handled directly via data binding.
Your ViewModel would just have some property, and you'd bind the TextBox.Visibility property directly to the ViewModel property.
The one "sticky point" is that you often will want to have some type of IValueConverter that will convert from your property type to a Visibility enum.

TextBox CaretIndex property in ViewModel

Is it possible to get/set the value of CaretIndex property of a TextBox control in viewmodel in wpf via Binding defined in view?
Thanks
You can not bind the property CaretIndex since it is not a DependencyProperty. It is a CLR
property that does not accept binding.
The issue here is how to get the CaretIndex of the TextBox control via the view model.
If you intent to get it directly by binding to the view model its impossible. As I posted in the previous answer its a CLR property and not a dependency property.
What can we do?
The best solution for that is to follow the steps:
Define attached property on the control via separate class.
Define a property in the view model and bind the attached property to the one in the view-model
Update the control property in the callback of the attached property changed event according to the new value received.
In this case, we still separate the view from the model.
I hope my answer helps you!

Resources