We Keep Coding

INotifyPropertyChanged vs Two way binding

I am newbie in c# and i want to know why we have to implement INotifyPropertyChanged interface when we use the TwoWay binding ?? and for the OneWay also ??
Thank you

In brief to support OneWay/TwoWay bindings, the underlying data must implement INotifyPropertyChanged.
Then the OneWay/TwoWay binding is just to choose the bind direction, you can find more here :
Various wpf binding modes

INotifyPropertyChanged,like the name, is to notify your client that your property has changed, see MSDN
You will need it for updating your UI when properties change.
OneWay(Source to Target): Propertychange will cause UI update and UI operation will NOT cause propertychange. *
TwoWay(Both way): Proerty and UI are fully binded, any of them change will affect the other one.
Binding works as long as you implement INotifyPropertyChanged for your property in this case.
If you don't, nothing will change even if you use Twoway.

Implementing INotifyPropertyChanged just offers classes (others than the one implementing it) the possibility to react on property changes.
This is not possible if that interface is not implemented because if a class instance, say A sets a property on B, a third class instance C cannot track that information. Setting that property is now only a concern of A and B. If Chowever knows that B does implement INotifyPropertyChanged, it can simply add an event handler to the event PropertyChanged (which is part of the interface) and react on it - still hoping that B will throw the event as expected.
Bindings need that information to update the model (data) or the view depending where the change happened. So basically, they are C listening for changes of other objects (A & B).

Property Changed event within class

I got a question about events within classes.
I have a whole load of properties within my class and want to fire an event whenever a property is changed. I want to use the changed properties to calculate a result.
One possible option might be adding a call to every single property-set but this is - for my understanding - too q'n'd.

The common approach to realise this would be to implement the INotitfyPropertyChanged interface and raise the PropertyChanged event in every settter method for the properties where you need it.
Then you implement an event handler which reacts to the event and performs the operations needed.
https://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged(v=vs.110).aspx

Visual inheritance for RadGridViews event handling possible?

I have 2 projects:
Project A which consists of a Usercontrol named BaseUC which consists of a RadPanel and a RadGridView (both have modifier set to public)
Project B which consists of a Usercontrol which inherits from BaseUC
(from the class itself). Project A is included as referenced dll in Project B
Now the situation is so:
Both elements from BaseUC are shown in the DerivedUC.
The RadLabel I can edit without problems (properties) in project B
The GridView has its properties grayed out in project B
If I give GridView events which I implement as virtual in project A and overwrite them in project B I run into the problem that I get an exception as soon as I try to fire the events. Same if I try to manually add events to the gridview in project B.
So my question is twofold there but comes down to the basic question if event handling is possible for visually inheritted RadGridViews:
How can I get the RadGridView to have its properties editable in design view in project B?
How can I handle events there?
That is if these two things are possible at all.

You can expose the child controls contained in your UserControl as a public property, that is creating a public property that returns the child control and not just making the child variable public. This will make the child control available to sink event handlers and set public properties. Note that this breaks one of object orientation rules namely, encapsulation....but rules are meant to be broken for certain cases that fits the requirement :)

Updating a PropertyGrid

How can I have a property grid update automatically when the object in its SelectedObject property changes? I've tried implementing INotifyPropertyChanged in my class but the property grid does not actually show the new propertyies of the object in the background until I click on it.
I've tried subscribing to the PropertyChanged event of my object directly, and calling the Refresh() method of the PropertyGrid when it is envoked. But some of my properties are related. Meaning changing one property may evoke multiple PropertyChanged events. This seems to work fine, but I'm still wondering if there is a cleaner way of doing this through DataBinding. Also I'd like to avoid having the control Refresh multiple times after the user only updated a single property.
So is there a way to get the PropertyGrid to refresh from PropertyChanged events?

Try adding the RefreshProperties attribute to each property that has dependencies:
[RefreshProperties(RefreshProperties.All)]
Now, each time this property changes - it will automatically refresh the other fields.
This is a much cleaner approach than calling the property-grid's "Refresh()" each time.

I don't know if there's a built-in way to do it, but here's a suggestion if you want to avoid multiple calls to Refresh for related properties :
When a PropertyChanged event occurs, start a timer. If the event occurs again before the timer has elapsed, do nothing. In the Tick event of the timer, refresh the PropertyGrid and stop the timer

C# - Events Question

Can any C# object be set up such that an event can be tied to it to fire when it's value changes? If so, how is this done? For example, let's take a very simple example. Say I have a variable declared as follows:
int i;
Is it possible to create an event that fires any time the value of i changes?
Thanks.

Well, you can't change fields so that events are fired when the value changes.
On the other hand, you can easily make it so that when a property changes, an event is fired. Only the author of the class containing the property can do this, however1 - you can't attach an event to an arbitrary existing class.
1 A slight exception would be a virtual property, which could be overridden solely for the purpose of raising the event. That would be pretty rare though.

Have a look at the INotifyPropertyChanged interface that can be implemented by a class and called by - at least some of - its properties to notify listeners that some values changed.

Another option would be to use the Observer pattern.
Grz, Kris.

Take a look at the PropertyChangedEvent pattern.