Hello, First of all i want to thank you for making these videos for wpf lerners. All the videos are V.Simple and easy to understanding. i just gone through your video for custom dependency property. I guess you miss used the property of counter while explaining the topic. What i mean to say is.... As per your demo "Counter" is a CLR property which holds the dependency property named "CounterProperty". Ok. While defining delegate for DispatcherTimer you have written the code like this. delegate { int newValue =0; if(Counter == int.MaxValue) { newValue = 0;} else {newValue = Counter + 1} SetValue(CounterProperty,newValue); } Here our intension is to updating clr property "Counter" using dependency property "CounterProperty", then what is the use of using Counter property in the delegate. you are already updating property "Counter" value and once again updating dependency property "CounterProperty". which is wrong i guess. i guess the example should be like this int newValue = 0; // Class level property if (newValue == int.MaxValue) newValue = 0; else newValue++; SetValue(CounterProperty, newValue); If i am wrong correct me.
In your code the verità of newValue la Airways 0 Counter is the actual value of the Real Counter La possibile che the code of assign 0 to new value if you put < in the if and remove the else...
who will notify the UI. Then you have to use INotifyPropertyChanged. With DP, he has eliminated that. thats my understanding. Anyone can correct me if I am wrong.
hi, i have gone through the prvious lecture of dependncy prop and custom dependency prop. i just wish to know that why are we using dependency property for counter when we can achieve this directly from common property. i mean what are its advantage of using dep prop? i understand you told difference b/w clr and dep property but i still didnt got the advantage of it
This demo was just to explain you how to create it. WPF internally uses DPs like Button Background.. So if understand how it notifies it is good, that is why I took a simple example. In real time projects there might be cases you need to create DPs, so you can start with this.. :-)
It was confused to people when and how we can use dependency property. Only when you need to use the property in xaml like background colour, a dependency property will be needed.
I agree with HH YY and Aakriti.... the same Counter increment could be easily achievable by using normal CLR property and implementing INotifyPropertyChanged. What was the need for using a dp here ? Please clarify
Dependency Property concept purely WILL BE USED , only if remove SetValue() func.call inside delegate, also remove newvalue references, and leave only Counter and directly work on Counter prop..... Namely; write: new DispatcherTimer(......, (a,b)=>{ Counter==int.MaxValue?Counter=0:Counter++; },.....) that's it! this way one shall expose the concept of DP. and what Dependency Means;)
But if our CLR property is raising PropertyChanged event of INotifyPropertyChanged, then we can bind the CLR property in binding. So where is the conceptual difference in both approaches?
Think... CLR property cannot be a target like Background of Button. CLR property could be Source. In databinding Target is always a DP. So when you say that you are binding CLR property you are using as a source.. By use of INOTIFY we can provide change notification from CLR prop but cannot make it a DP that acts like a Target..
The example is a bit too simple. In real life, you would create a custom WPF control and create custom dependency properties inside it so the properties can be accessed in XAML when you want to use that custom control in your application. A better example would be to create a custom control for setting an integer value with an Up and Down buttons and a text block to display the current value. In that situation, it would make sense to create 3 dependency properties for the control: one for the current value (may named Value), one for setting the minimum value and one for setting the maximum value. In XAML you would then be able to use these dependency properties like this . Furthermore, you would be able to use binding on 'Value' to read and update a value in one of your classes automatically like Value="{Binding Path=MyApplicationIntValue, Mode=TwoWay}" and that would work.
Hi, There are several ways to set the data context here ElementName binding has been used. you can remove that ElementName by adding "this.DataContext=this" in the code behind constructor. thank you
Sorry but the example is rather useless, because it doesn't expose the real concept of dependency property in behind WPF...Because what has been achieved in the video is actually is making things harder , when there is a simpler one, still sticking with the same code layout.... There is NO NEED to SETVALUE of DP in delegate function, one should LOGICALLY ,in this problem setup, increase the COUNTER property per se, and just implement INOTIFY for the owner class...i mean to refer a DP in behind, is totally MEANINGLESS,in such an example...sorry... to get the real concept of DP, one must surely extend functionality of existing properties of WPF core classes.
thank you for the video. very helpful :)
Excellent help and explanation
It's working. Thanks. Old is Gold
Really nice, I was desperately searching for this kind of tutorial. Thank you and keep it up!!!!
좋은 영상 감사합니다. 덕분에 많이 배웠습니다
Hello,
First of all i want to thank you for making these videos for wpf lerners. All the videos are V.Simple and easy to understanding.
i just gone through your video for custom dependency property. I guess you miss used the property of counter while explaining the topic. What i mean to say is....
As per your demo "Counter" is a CLR property which holds the dependency property named "CounterProperty". Ok.
While defining delegate for DispatcherTimer you have written the code like this.
delegate {
int newValue =0;
if(Counter == int.MaxValue)
{ newValue = 0;}
else {newValue = Counter + 1}
SetValue(CounterProperty,newValue);
}
Here our intension is to updating clr property "Counter" using dependency property "CounterProperty", then what is the use of using Counter property in the delegate. you are already updating property "Counter" value and once again updating dependency property "CounterProperty". which is wrong i guess.
i guess the example should be like this
int newValue = 0; // Class level property
if (newValue == int.MaxValue)
newValue = 0;
else
newValue++;
SetValue(CounterProperty, newValue);
If i am wrong correct me.
In your code the verità of newValue la Airways 0
Counter is the actual value of the Real Counter
La possibile che the code of assign 0 to new value if you put < in the if and remove the else...
Very helpful !! I'm watching all yours tutorials. Тhankfull :)
Thanks Neytiri ..... :-).. Please share it with your friends. Keep learning.
Very nice videos, you explain the concepts very well.
In 14:03 you just closed your windows at exatly 200. Wow, thumbs up for that ;)
Amazing!!!
Hi nice explained, but this not looks like familier example, but it was nice
nice explanation.. thanks!
Why don't you want to use the Counter's setter? It's easier and less error prone to write Counter = newValue instead of the SetValue method call.
Yes, you are right. I think the teacher does not understand fully the concept even though it's a useful video.
who will notify the UI. Then you have to use INotifyPropertyChanged. With DP, he has eliminated that. thats my understanding. Anyone can correct me if I am wrong.
Very nice videos
nice video and very helpful.can you explain how usercontrol used in wpf
Thanks.. Will upload a video on it.
Dunno why, but this accent is so cute
Can you please give one more example of Custom Dependency Property so that it would be more clear . Thanks
hi, i have gone through the prvious lecture of dependncy prop and custom dependency prop. i just wish to know that why are we using dependency property for counter when we can achieve this directly from common property. i mean what are its advantage of using dep prop? i understand you told difference b/w clr and dep property but i still didnt got the advantage of it
This demo was just to explain you how to create it. WPF internally uses DPs like Button Background.. So if understand how it notifies it is good, that is why I took a simple example. In real time projects there might be cases you need to create DPs, so you can start with this.. :-)
I agreed with Aakriti, it was no need to use dependency property in your demo, @@dotnetskoool5809
It was confused to people when and how we can use dependency property. Only when you need to use the property in xaml like background colour, a dependency property will be needed.
If you only need to bind as a data in xaml like that in the demo, a normal property is enough.
I agree with HH YY and Aakriti.... the same Counter increment could be easily achievable by using normal CLR property and implementing INotifyPropertyChanged. What was the need for using a dp here ? Please clarify
could you do a video on user control inheritance in wpf
Dependency Property concept purely WILL BE USED , only if remove SetValue() func.call inside delegate, also remove newvalue references, and leave only Counter and directly work on Counter prop..... Namely; write: new DispatcherTimer(......, (a,b)=>{ Counter==int.MaxValue?Counter=0:Counter++; },.....) that's it! this way one shall expose the concept of DP. and what Dependency Means;)
Is there a way or a reason to create a Class (Person) dependency property and pass it in from xaml by binding it?
Nice video, good explanation of concept, I have one question, when to use dependency properties over normal or CLR properties, can you explain ?
If you work with WPF you are using DPs behind the scenes. When you do data binding you use DPs.. Normal CLR do not support databinding, styling etc...
Got it.. Thanks for clearing my doubt.
But if our CLR property is raising PropertyChanged event of INotifyPropertyChanged, then we can bind the CLR property in binding. So where is the conceptual difference in both approaches?
Think... CLR property cannot be a target like Background of Button. CLR property could be Source. In databinding Target is always a DP. So when you say that you are binding CLR property you are using as a source.. By use of INOTIFY we can provide change notification from CLR prop but cannot make it a DP that acts like a Target..
But haven't you use this dp in code as a source?
What is the functional difference between using a dynamic resource and a dependency property for solving these problems?
The example is a bit too simple. In real life, you would create a custom WPF control and create custom dependency properties inside it so the properties can be accessed in XAML when you want to use that custom control in your application. A better example would be to create a custom control for setting an integer value with an Up and Down buttons and a text block to display the current value. In that situation, it would make sense to create 3 dependency properties for the control: one for the current value (may named Value), one for setting the minimum value and one for setting the maximum value. In XAML you would then be able to use these dependency properties like this . Furthermore, you would be able to use binding on 'Value' to read and update a value in one of your classes automatically like Value="{Binding Path=MyApplicationIntValue, Mode=TwoWay}" and that would work.
Hi, I still cannot understand why binding ElementName is required? When do we need that? Thanks.
Hi, There are several ways to set the data context here ElementName binding has been used. you can remove that ElementName by adding "this.DataContext=this" in the code behind constructor.
thank you
Sorry but the example is rather useless, because it doesn't expose the real concept of dependency property in behind WPF...Because what has been achieved in the video is actually is making things harder , when there is a simpler one, still sticking with the same code layout.... There is NO NEED to SETVALUE of DP in delegate function, one should LOGICALLY ,in this problem setup, increase the COUNTER property per se, and just implement INOTIFY for the owner class...i mean to refer a DP in behind, is totally MEANINGLESS,in such an example...sorry... to get the real concept of DP, one must surely extend functionality of existing properties of WPF core classes.
You have made it too complicated.
Sry this is stupide why custom Dependency Property for this. and than you explain disptacher more then the custom Dependency Property.