Property Change Event WPF Original to change - wpf

I am new to WPF and piecing it together as I go along, but there is a property change event that is attached to fields that I am utlizing to know when something has changed, off those events is their a way to know if the value has changed is different then from the original value and back and forth, right now I have a collection of default values that I am checking against to know is something has changed and also when I have to reassign the default values the property event keeps getting fired

Usually there will be a backing private field for these public properties where you have Raise or OnPropertyChanged being called (however you do it). You can usually compare the incoming "value" to the backing field before you set it. So any type of comparison of the incoming value vs the value that the field is before being set can be done right there in the property setter.
Something like this
private bool bMyBool;
public bool MyBool
{
get
{
return bMyBool;
}
set
{
// Can do comparison here
// if (value == bMyBool)
// DoSomething
bMyBool = value;
OnPropertyChanged("MyBool"); // Or some type on property changed notification
}
}

If you don't want the value changed then just eliminate the get
private string myValue = "default";
public string MyValue;
{
get { return myValue; }
set
{
if (myValue == value) return;
myValue = value;
NotifyPropertyChanged(MyValue);
}
}
If you want to change the value but not NotifyPropertyChanged then you could assign
myValue = "no notitfy";
Rare you would want to do that

Related

Dependecy properties that depend on other properties

Class C implements INotifyPropertyChanged.
Assume the C has Length, Width and Area propreties, where Area = Length * Width. A change in either might cause a change in area. All three are bound, i.e. the UI expects all three to notify of changes in their values.
When either Length or Width change, their setters call NotifyPropertyChanged.
How should I treat the calculated Area property? Currently the pattern I can think of is detecting in NotifyPropertyChanged whether the changed property is either Length or Width and, if such is the case, initiate an addional PropertyChanged notification for Area. This, however, requires that I maintain inside NotifyPropertyChanged the dependencies graph, which I feel is an anti-pattern.
So, my question is: How should I code dependency properties that depend on other dependency properties?
edit: People here suggested that Length and Width also call NotifyPropertyChanged for Area. Again, I think this is an anti-pattern. A property (IMHO) shouldn't be aware of who depends on it, as shouldn't NotifyPropertyChanged. Only the property should be aware of who it depends on.
This issue kept on bugging me, so I re-opened it.
First, I'd like to appologize for anyone taking my "anti-pattern" comment personally. The solutions offered here were, indeed, how-it's-done in WPF. However, still, IMHO they're bad practices caused, deficiencies in ther framework.
My claim is that the information hiding guide dictates that when B depeneds on A, A should not be aware of B. For exmaple, when B derives from A, A should not have code saying: "If my runtime type is really a B, then do this and that". Simiarily, when B uses A, A should not have code saying: "If the object calling this method is a B, then ..."
So it follows that if property B depends on property A, A shouldn't be the one who's responsible to alert B directly.
Conversely, maintaining (as I currently do) the dependencies graph inside NotifyPropertyChanged is also an anti-pattern. That method should be lightweight and do what it name states, not maintain dependency relationships between properties.
So, I think the solution needed is through aspect oriented programming: Peroperty B should use an "I-depend-on(Property A)" attribute, and some code-rewriter should create the dependency graph and modify NotifyPropertyChanged transparently.
Today, I'm a single programmer working on a single product, so I can't justify dvelving with this any more, but this, I feel, is the correct solution.
Here is an article describing how to create a custom attribute that automatically calls PropertyChanged for properties depending on another property: http://www.redmountainsw.com/wordpress/2012/01/17/a-nicer-way-to-handle-dependent-values-on-propertychanged/
The code will look like this:
[DependsOn("A")]
[DependsOn("B")]
public int Total
{
get { return A + B; }
}
public int A
{
get { return m_A; }
set { m_A = value; RaisePropertyChanged("A"); }
}
public int B
{
get { return m_B: }
set { m_B = value; RaisePropertyChanged("B"); }
}
I haven't tried it myself but I like the idea
When the Length or Width properties are changed you fire PropertyChanged for Area in addition to firing it for either Length or Width.
Here is a very simple implementation based on backing fields and the method OnPropertyChanged to fire the PropertyChanged event:
public Double Length {
get { return this.length; }
set {
this.length = value;
OnPropertyChanged("Length");
OnPropertyChanged("Area");
}
}
public Double Width {
get { return this.width; }
set {
this.width = value;
OnPropertyChanged("Width");
OnPropertyChanged("Area");
}
}
public Double Area {
get { return this.length*this.width; }
}
Doing it like this is certainly not an anti-pattern. That is exactly the pattern for doing it. You as the implementer of the class knows that when Length is changed then Area is also changed and you encode it by raising the appropriate event.
Then you should raise twice, in Length and Width property setters. One for the actual property and one for the Area property.
for example:
private int _width;
public int Width
{
get { return _width; }
set
{
if (_width == value) return;
_width = value;
NotifyPropertyChanged("Width");
NotifyPropertyChanged("Area");
}
}
People here suggested that Length and Width also call
NotifyPropertyChanged for Area. Again, I think this is an
anti-pattern. A property (IMHO) shouldn't be aware of who depends on
it, as shouldn't NotifyPropertyChanged. Only the property should be
aware of who it depends on.
This is not an anti-pattern. Actually, your data encapsulated inside this class, so this class knows when and what changed. You shouldn't know outside of this class that Area depends on Width and Length. So the most logical place to notify listeners about Area is the Width and Length setter.
A property (IMHO) shouldn't be aware of who depends on it, as
shouldn't NotifyPropertyChanged.
It does not break encapsulation, because you are in the same class, in the same data structure.
An extra information is that knockout.js (a javascript mvvm library) has a concept which accessing this problem: Computed Observables. So I believe this is absolutely acceptable.
Here is a possible implementation of an attribute:
public class DependentPropertiesAttribute : Attribute
{
private readonly string[] properties;
public DependentPropertiesAttribute(params string[] dp)
{
properties = dp;
}
public string[] Properties
{
get
{
return properties;
}
}
}
Then in the Base View Model, we handle the mechanism of calling property dependencies:
public class ViewModelBase : INotifyPropertyChanged
{
public ViewModelBase()
{
DetectPropertiesDependencies();
}
private readonly Dictionary<string, List<string>> _dependencies = new Dictionary<string, List<string>>();
private void DetectPropertiesDependencies()
{
var propertyInfoWithDependencies = GetType().GetProperties().Where(
prop => Attribute.IsDefined(prop, typeof(DependentPropertiesAttribute))).ToArray();
foreach (PropertyInfo propertyInfo in propertyInfoWithDependencies)
{
var ca = propertyInfo.GetCustomAttributes(false).OfType<DependentPropertiesAttribute>().Single();
if (ca.Properties != null)
{
foreach (string prop in ca.Properties)
{
if (!_dependencies.ContainsKey(prop))
{
_dependencies.Add(prop, new List<string>());
}
_dependencies[prop].Add(propertyInfo.Name);
}
}
}
}
protected void OnPropertyChanged(params Expression<Func<object>>[] expressions)
{
expressions.Select(expr => ReflectionHelper.GetPropertyName(expr)).ToList().ForEach(p => {
RaisePropertyChanged(p);
RaiseDependentProperties(p, new List<string>() { p });
});
}
public event PropertyChangedEventHandler PropertyChanged = delegate { };
protected virtual void RaisePropertyChanged(string propertyName)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
protected void RaiseDependentProperties(string propertyName, List<string> calledProperties = null)
{
if (!_dependencies.Any() || !_dependencies.ContainsKey(propertyName))
return;
if (calledProperties == null)
calledProperties = new List<string>();
List<string> dependentProperties = _dependencies[propertyName];
foreach (var dependentProperty in dependentProperties)
{
if (!calledProperties.Contains(dependentProperty))
{
RaisePropertyChanged(dependentProperty);
RaiseDependentProperties(dependentProperty, calledProperties);
}
}
}
}
Finally we define dependencies in our ViewModel
[DependentProperties("Prop1", "Prop2")]
public bool SomeCalculatedProperty
{
get
{
return Prop1 + Prop2;
}
}

DependencyProperty doesn't fire ValueChanged when new value is the same

Ok so here's the problem: I wrote a UserControl which receives a new value say like every 100ms and does something with it. It has to handle each new value setter, even if the value didn't change. The UserControl has a few DependencyProperties:
public double CurrentValue
{
get { return (double)GetValue(CurrentValueProperty); }
set { SetValue(CurrentValueProperty, value); }
}
public static readonly DependencyProperty CurrentValueProperty =
DependencyProperty.Register("CurrentValue", typeof(double), typeof(GraphControl), new UIPropertyMetadata(0d));
In the XAML where this control is used, I just set the Binding of CurrentValue to a (INotifyPropertyChanged-enabled) property:
<uc:UserControl CurrentValue="{Binding MyValue}" ... />
viewmodel:
public double MyValue
{
get { return _value; }
set
{
//if (_value == value) return;
_value= value;
if (PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs("MyValue"));
}
}
As you can see, I explicitly commented out the if equals then return so it will fire the PropertyChanged event even when the value gets updated to the same value.
Now back to my user control, I tried registering the ValueChanged in two ways; first by using the DependencyPropertyDescriptor:
var propertyDescriptor = DependencyPropertyDescriptor.FromProperty(CurrentValueProperty, typeof(GraphControl));
propertyDescriptor.AddValueChanged(this, OnCurrentValueChanged);
or by using the UIPropertyMetaData:
new UIPropertyMetadata(0d, OnCurrentValueChangedCallback)
so a stub of the callback would look like:
private void Callback(object sender, EventArgs e){
//do stuff
}
Ok now the problem is, the callback is not fired when the value doesn't explicitly change. I checked, and the PropertyChanged event is firing in my viewmodel, but the control doesn't see the change. When the value changes to a new value, it will handle the callback as expected.
Is there any way to override this behavior so that my callback method will always get hit?
EDIT:
I also tried using the CoerceValueCallback, and that one is hit when the value stays the same, but it doesn't help me with my problem I think...
You can wrap your value up in an object, i.e. create a class to hold it - then set the property to a new instance of that class containing the new value, every time. That means you're creating ~10 objects per second, but they are each different, will trigger the change event, and are only small (will be GC'd anyway). :)
Another alternative is to switch the value temporarily to something else then restore the previous one. You can do this entire trick transparently in the Coerce callback as such:
public static readonly DependencyProperty TestProperty = DependencyProperty.Register(
"Test", typeof(object), typeof(School),
new PropertyMetadata(null, TestChangedCallback, TestCoerceCallback));
static object TestCoerceCallback(DependencyObject d, object baseValue)
{
if (baseValue != null && (d.GetValue(TestProperty) == baseValue))
{
d.SetCurrentValue(TestProperty, null);
d.SetCurrentValue(TestProperty, baseValue);
}
return baseValue;
}
Just make sure your property code can handle the null value case gracefully.

How to use PropertyChanged to pass trough DataTemplate?

Question is simple: how can I trigger a change on the dataObject without acutaly changing the dataObject, and see this change on the visual?
DataObject:
ProductData : INotifyPropertyChanged
{
private ProductPartData myProductPartData;
public ProductPartData ProductPartData
{
get
{
return myProductPartData;
}
set
{
if (value != myProductPartData)
{
myProductPartData = value;
OnNotifyPropertyChanged("ProductPartData");
}
}
}
}
DataTemplate:
<DataTemplate
DataType="{x:Type ProductData}"
>
<VisualProduct
ProductPartData="{Binding Path=ProductPartData, Mode=OneWay}"
/>
</DataTemplate>
And now in a VM I have:
product.OnNotifyPropertyChanged("ProductPartData");
Problem:
Even if the getter for ProductPart is called when I execute OnNotifyPropertyChanged, the visual is not notified, because is the same instance of the ProductPartData.
How do I trigger a change seen by the Visual without changing the instance?
Thank you,
Daniel,
A solution is to use UpdateTarget() method of the BindingExpression class, this way the target of the binding gets refreshed no matter what; of course, your converter will also be hit - if any. Since I'm guessing you don't have access to your visual in the Product, you could use an attached property and in its callback, you can get the BindingExpression and call UpdateTarget() on it.
Note that I'm using a simple TextBlock as the visual of the data object.
public class BindingHelper
{
public static bool GetRefreshBinding(DependencyObject obj)
{
return (bool) obj.GetValue(RefreshBindingProperty);
}
public static void SetRefreshBinding(DependencyObject obj, bool value)
{
obj.SetValue(RefreshBindingProperty, value);
}
// Using a DependencyProperty as the backing store for RefreshBinding. This enables animation, styling, binding, etc...
public static readonly DependencyProperty RefreshBindingProperty =
DependencyProperty.RegisterAttached("RefreshBinding", typeof(bool), typeof(BindingHelper), new UIPropertyMetadata(false, OnRefreshBindingPropertyChanged));
static void OnRefreshBindingPropertyChanged(DependencyObject o, DependencyPropertyChangedEventArgs ea)
{
TextBlock elem = o as TextBlock;
if (elem != null)
{
BindingExpression bEx = elem.GetBindingExpression(TextBlock.TextProperty);
if (bEx != null)
{
bEx.UpdateTarget();
}
}
}
}
Also, in your data object that you can create a new bool property(let's name it ShouldRefresh) that is bound to the attached property within the template - this will trigger the AP's property changing:
<DataTemplate DataType="{x:Type local:ProductData}">
<TextBlock Text="{Binding Path=Name, Converter={StaticResource BlankConverter}}"
local:BindingHelper.RefreshBinding="{Binding Path=ShouldRefresh}"/>
</DataTemplate>
So, this way, whenever you want to update the target through binding, you can set:
ShouldRefresh = !ShouldRefresh
in your data class.
HTH.
If you raise a PropertyChanged event and the new value of the property is equal to the value WPF already has, it will simply ignore you. You have a couple of options:
The "fast" way is to set the property to null and then back to the correct value again, ensuring PropertyChanged events are raised each time. It's dirty but it works every time.
The "right" way is to force a binding refresh as discussed in this post by Jaime Rodriguez. Because your visual is data-templated though getting the "dependencyObject" to pass into the call in that post is a little tricky. You may end up needing to use the template's FindName method as discussed in this post by Josh Smith.
We encountered this kind of issue with data coming from a database and converted to a DTO (data transfert object).
Our base class for DTO override Object's method such as Equals() and GetHashCode() as follow:
public override Boolean Equals(Object obj)
{
// Null reference
if (null == obj)
return false;
// Same reference
if (Object.ReferenceEquals(this, obj))
return true;
EntityDTOBase<TEntity> entiteObj = obj as EntityDTOBase<TEntity>;
if (null == entiteObj)
return false;
else
return Equals(entiteObj);
}
public Boolean Equals(EntityDTOBase<TEntity> other)
{
// Null reference
if (null == other)
return false;
// Same reference
if (Object.ReferenceEquals(this, other))
return true;
// No Id: cannot be compared, return false
if (this.id == TypeHelper.DefaultValue<long>())
return false;
// Id comparison
if (this.id != other.id)
return false;
return true;
}
public override Int32 GetHashCode()
{
return this.id.GetHashCode();
}
So the problem was when we load again the same entity from the database, since the ID is the same, some binding were not properly updated.
This particular issue was circumvented by adding an additional virtual EqualsExtended() method which default implementation simply returns true:
protected virtual Boolean EqualsExtended(EntityDTOBase<TEntity> other)
{
return true;
}
public Boolean Equals(EntityDTOBase<TEntity> other)
{
/// Same code as before (except last line):
return EqualsExtended(other);
}
Now in any implementation of our DTO class we can add some logic to make Equals() returning false in some situations, for example by adding a timestamp when data is retrieved from the database :
protected override Boolean EqualsExtended(EntityDTOBase<Act> other
{
if (this.Timestamp != other.Timestamp)
{
return false;
}
return true;
}
Long story short, one way to workaround this issue is to make your class instance look different whenever you want the GUI to update accordingly.
The problem might be that you are returning GuiProductPartData typed myProductPartData with ProductPartData typed ProductPartData? But in any case this shouldn't be like this :)
Also it's not a great practice to have the variable name same as the type, so you shouldn't have a ProductPartData ProductPartData property.
Naming conventions aside (and assuming just typos on the typing) the problem probably resides inside your ProductPartData class. Does it implement INotifyPropertyChanged as well?

WPF binding not applying to target after initialization

I am trying to add Series binding to the Visifire graphing controls set. To this end i have created a SeriesSource dependency property of time DataSeriesCollection. This is bound in the front end using:
`<Chart SeriesSource={Binding Series} />`
Problem
When the source changes, the validation callback is called. The value that is passed to this is the correct value, a populated ObservableCollection<something>. Immediately after the validate value is called, the CoerceValue callback is called by something, and the value that is sent to it is an EMPTY ObservableCollection<something>. Bounty will go to anyone who can:
Get the correct populated ObservableCollection<someting> passed to the CoerceValue callback OR
Get the correct value being passed to the OnSeriesSourceChanged callback OR
Explain to me how i can do any of the above :)
Here is the data template for the view:
<DataTemplate DataType="{x:Type vm:ReportViewModel}">
<Grid Name="rootGrid">
<visifire:Chart Grid.Row="1" SeriesSource="{Binding Series}">
<visifire:Chart.AxesX>
<visifire:Axis Title="X axis" />
</visifire:Chart.AxesX>
<visifire:Chart.AxesY>
<visifire:Axis Title="Y axis" />
</visifire:Chart.AxesY>
</visifire:Chart>
</Grid>
</DataTemplate>
Here is the target Dependency Property
//Getter and setter for Dependency Property
public ObservableCollection<DataSeries> SeriesSource
{
get { return (ObservableCollection<DataSeries>)GetValue(SeriesSourceProperty); }
set { SetValue(SeriesSourceProperty, value); }
}
// Using a DependencyProperty as the backing store for SeriesSource. This enables animation, styling, binding, etc...
public static readonly DependencyProperty SeriesSourceProperty =
DependencyProperty.Register("SeriesSource", typeof(ObservableCollection<DataSeries>), typeof(Chart), new UIPropertyMetadata(new ObservableCollection<DataSeries>(), new PropertyChangedCallback(OnSeriesSourceChange), new CoerceValueCallback(CoerceSeries)), new ValidateValueCallback(ValidateSeriesSource));
//Value validation callback
private static bool ValidateSeriesSource(object value)
{
if (value as ObservableCollection<DataSeries> != null)
return true;
return false;
}
//Dependency Property Changed callback
private static void OnSeriesSourceChange(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
Chart c = d as Chart;
if (c == null)
return;
//This line was causing the issue. It was overriding the setter
c.SeriesSource = (DataSeriesCollection)e.NewValue;
}
//Coerce Value callback
private static object CoerceSeries(DependencyObject d, object value)
{
Chart c = d as Chart;
var collection = value as System.Collections.ObjectModel.ObservableCollection<Visifire.Charts.DataSeries>;
foreach (var item in c.Series)
{
if (!collection.Contains(item))
c.Series.Remove(item);
}
foreach (var item in collection)
{
if (!c.Series.Contains(item))
c.Series.Add(item);
}
return collection;
}
New information
The value being received by the CoerceValue callback is ALWAYS the first value which that property was set to. So if the first value i pass it is a list with 1 item, it will always coerce the value back to a list with one item!
Edit: found the issue, it was in the property changed callback. Credit goes to Matt for helping me out with the CoerceValue callback
This may not be the exact problem, but you have logic in your setter. That code isn't going to be executed when the property is assigned via a binding.
Instead of adding logic to your setter, consider using a "coerced" callback which gets called every time a value is assigned to your property. See here for more details about "coerce value" callbacks. They're very similar to what you've done for your "property changed" callback.

WPF two-way binding: how do I update a TextBox with a formatted version of the value it just set?

I have a class, called DateField, that has a string Value property. If you set this property to a string that can be parsed into a valid date, the property setter sets Value to the properly formatted date, e.g.:
private string _Value;
public string Value
{
get
{
return _Value;
}
set
{
if (value == _Value)
{
return;
}
object result;
if (TryParse(value, out result))
{
_Value = Format(result);
}
else
{
_Value = value;
}
OnPropertyChanged("Value");
}
}
I create a TextBox that's bound to this field:
<DataTemplate DataType="{x:Type m:DateField}">
<TextBox
IsTabStop="True"
Text="{Binding Value, Mode=TwoWay, ValidatesOnDataErrors=True}">
</TextBox>
</DataTemplate>
When I enter, say, "010109" into this field and tab out of it, the Binding appropriately sets the Value property to this string. The property setter runs, _Value gets correctly set to "01/01/2009" (the TryParse implementation in this class is a little more catholic in what it accepts than DateTime.TryParse is), and the PropertyChanged event gets raised. I know this last bit is happening because another object that's subscribed to the list gets updated.
But the TextBox doesn't. Why not? I've set Value, I've raised PropertyChanged; what more do I need to be doing?
I think you should use a converter and implement both the Convert and the ConvertBack methods
I think I have this working properly, but I'm not entirely happy with how I've done it.
The typical pattern for using a ValueConverter is that the ConvertBack should return the converted value if parsing succeeded, and DependencyProperty.UnsetValue if it failed. I can't do that. If I do that, the bound Value property doesn't get set. So the value doesn't get validated, and no validation error doesn't shows up in the UI.
What I've done instead is implemented a DateValueConverter class whose ConvertBack method returns either the parsed DateTime, or the string that it unsuccessfully tried to convert. The Value property in my DateTimeField class (actually, in the Field class it's derived from) looks like this:
public object Value
{
get
{
return _Value;
}
set
{
if (value == _Value)
{
return;
}
if (!Validate(value))
{
return;
}
_Value = value;
OnPropertyChanged("Value");
}
}
The Validate method basically just looks at the type of the value being passed in: if it's a DateTime, then it's valid; if it's a string, it's not.
I'm not happy with this because it seems like a ValueConverter shouldn't convert a value into two different types. It feels like a hack. But maybe it's okay. I need to think about this some more.

Resources