I've just answered a question over here where I said that there is no functional difference between
{Binding TargetProperty}
and
{Binding Path=TargetProperty}
and, as far as I'm aware what I have written is fundamentally correct. However the idea that one will use the constructor and the other sets the property got me thinking that there could be a difference, so I whipped open reflector and had a look.
The constructor has the following code in it:
public Binding(string path)
{
this._source = UnsetSource;
if (path != null)
{
if (Dispatcher.CurrentDispatcher == null)
{
throw new InvalidOperationException();
}
this._ppath = new PropertyPath(path, new object[0]);
this._attachedPropertiesInPath = -1;
}
}
The path property is this:
public PropertyPath Path
{
get
{
return this._ppath;
}
set
{
base.CheckSealed();
this._ppath = value;
this._attachedPropertiesInPath = -1;
base.ClearFlag(BindingBase.BindingFlags.PathGeneratedInternally);
}
}
So when you set the path through the property the PathGeneratedInternally flag is cleared. Now, this flag isn't exposed anywhere publicly directly, but it does seem to be used in a few places:
internal void UsePath(PropertyPath path)
{
this._ppath = path;
base.SetFlag(BindingBase.BindingFlags.PathGeneratedInternally);
}
[EditorBrowsable(EditorBrowsableState.Never)]
public bool ShouldSerializePath()
{
return ((this._ppath != null) && !base.TestFlag(BindingBase.BindingFlags.PathGeneratedInternally));
}
I'm sure it's all fairly inconsequential, but does anyone out there know what this flag means and why it maybe different depending on how you declare the binding?
The key is to see where the UsePath method is referenced from. By default the flag won't be set, so clearing it is basically a no-op. There is no reason to clear it in the constructor, because you know it hasn't been set in that case (because the object is still being constructed).
The UsePath method is only called in one location and that's the ClrBindingWorker constructor. If you look in there you will see they automatically create a "blank" or "empty" path and pass that to UsePath.
I suspect they do this so the Path is "valid" when used internally, even if it just refers to the binding source (which is the default behavior when no path is given). If you later set the Path property on the Binding, the flag that indicates the Path was automatically generated must be cleared.
Related
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
I've a method that when called returns a LinearGradientBrush with random color for the GradientStop and I use on them mylabel.RegisterName for later use in a storyboard animation.
To prevent the error on first call where no registered name are present I do this:
try
{
myLabel.UnregisterName("GS1");
myLabel.UnregisterName("GS2");
myLabel.UnregisterName("GS3");
myLabel.UnregisterName("GS4");
}
catch
{
}
I have not found a way to overwrite registered name. There's a better way to do this?
What about UnregisterName?
(That's what I get for attempting to answer when I can only read part of the question...)
Digging around a bit more, may have found another (WAY simpler) alternative:
var isGs1Defined = NameScope.GetNameScope(myLabel).FindName("GS1") == null;
or packaged up nicely:
public static bool IsNameRegistered(DependencyObject depObject, string name)
{
var namescope = NameScope.GetNameScope(depObject);
if(namescope == null)
return false;
return namescope.FindName(name) != null;
}
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;
}
}
I'm creating a custom ToolTip that needs to get a reference to another control. It's very similar to how Storyboard.TargetName would work. Now I've rolled my own implementation on how to get the target reference such as (note that my target will always be a parent of the ToolTip):
public object FindTarget(string targetName)
{
var target = default(object);
FrameworkElement item = this;
while ((item = item.Parent as FrameworkElement) != null && target == null)
target = item.FindName(targetName);
return target;
}
My question is is there a way to do this that's built into the framework? It seems like this is a common enough task that it would be.
Edit:
Turns out the above algorithm doesn't actually work for ToolTips because their Parent property is always null. I'm assuming ToolTips are based on Popups and this is why the Parent is null.
You can use extension methods to make it visible from anywhere you want:
public static object GetElementByName(this FrameworkElement baseElement, string name)
{
object target = null;
FrameworkElement item = baseElement;
while ((item = item.Parent as FrameworkElement) != null && target == null)
target = item.FindName(name);
return target;
}
After this you are able to call this method on any FrameworkElement.
Although you should be aware of the fact that FindName will not work for names defined in Templates.
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?