I have a custom control in which I created a custom DependencyProperty called TheObject that can contain a generic object.
<comp:MyControl TheObject="{Binding Country}" />
Sometimes, I need to set the TheObject internally (by code, internally to the control).
I did something like this:
this.TheObject = new Country();
But I realized that it is causing the loss of the DataBinding and the control becomes not responding to data changes.
What I really want is that this new object remains attached to the existing DataBinding of the property.
Use SetCurrentValue:
This method is used by a component that programmatically sets the value of one of its own properties without disabling an application's declared use of the property. The SetCurrentValue method changes the effective value of the property, but existing triggers, data bindings, and styles will continue to work.
this.SetCurrentValue(TheObjectProperty, new Country());
Related
I am not sure that I fully understand the advantage of binding. For example, if I want to bind a string value to a TextBlock I need to do the following:
Create a class that extends INotifyPropertyChanged
Add a string to that class (say: MyString)
Extend the set method for MyString so that it calls another method (say: OnPropertyChanged)
Create the OnPropertyChanged method to call the PropertyChangedEventHandler event
Then I need to create a new instance of the class, set my TextBlock.DataContext to point to that class, and finally add the XAML bit for the binding.
Can someone explain the advantage of this over simply setting:
TextBlock.Text = MyString;
Thanks!
Any changes to MyString won't be automatically reflected in your UI.
Your code behind will be littered with "when this event occurs, update these pieces of data", so you'll essentially be writing your own messy data binding logic for each and every view.
The advantage is that you can both change and display the value in multiple places, without having to update some method to add another TextBlock assignment each time the value changes. Any new display control just binds itself to the property, the rest is automatic.
Now if you really just set the value in one place and show it in one control, then you're right, there's not much point.
The gain of using Data Binding isn't particularly noticeable for a TextBlock binding to a static string.
However if the value of MyString changes during application runtime it becomes much more useful - especially in a case where the object that owns that property is unaware of the TextBlock. This separation between UI and the underlying data layer can be created using a design pattern such as MVVM.
Data Binding is also useful for more complex properties such as Items in a ListBox control. Just bind the ListBox.Items to a property that is of type ObservableCollection and the UI will automatically update whenever the content of that collection changes.
I do not understand the various data binding modes in WPF, such as:
One-Way
Two-Way
One-Time
etc...
What does each of these modes mean?
When should they be used?
OneWay: Use this when you want the bound property to update the user interface.
TwoWay: This has the same behavior as OneWay and OneWayToSource combined. The bound property will update the user interface, and changes in the user interface will update the bound property (You would use this with a TextBox or a Checkbox, for example.)
OneTime: This has the same behavior as OneWay, except it will only update the user interface one time. This should be your default choice for binding (for various reasons I won't elaborate on here). You should only use other types of bindings if you actually need the extra functionality.
OneWayToSource: This is the opposite of OneWay -- user interface value changes update the bound property.
If you don't specify anything, then the behavior will depend on the control that you are using.
For more info, see BindingMode enum on Microsoft Docs.
A binding consists of two entities:
The Source (Typically the ViewModel in MVVM scenarios)
The Target (The UI control)
The target has to be a DependencyObject (for binding to work) and the source can be either a DependencyObject or it should have some mechanism to imitate the WPF Binding system about it being changed (Implemeting INotifyPropetyChnaged interface).
MVVM recommends the ViewModel project to be free from any View related references and hence it is recommended to use INotifyPropertyChanged interface to make the Source object being heard by WPF binding.
Binding happens between a property of Source and a property of Target (has to be a DependencyProperty).
e.g. The TextPropertyof the TextBox class is DataBound to (say) UserName property of the view model.
WPF binding offers four types of Binding. Remember, Binding runs on UI thread unless otherwise you specify it to run otherwise.
OneWay: The target property will listen to the source property being changed and will update itself. If you programmatically change the ViewwModel's UserName property, it will reflect in the text box. This is of intermediate cost as the binding system watches only Source for changes.
TwoWay: The target property will listen to the source property being changed and will update itself. AND The source property will listen to the target property being changed and will update itself. Both the TextProperty and the UserName property will remain in sync and will update each other if one changes. This is most costly as the binding system has to watch both sides for change.
OneWayToSource: The Source property will change if the target property is changed. If the user changes the TextProperty, the UserName property will take up the changed value. This again is of intermediate cost as the binding system watches only Target for changes.
OneTime: This happens only once during the lifetime of Binding, the Target property will be updated with the Source property when the Binding happens. This is least costly and is advisable for scenarios where you have static data to be shown e.g. Label, TextBlock etc.
If you don't mention anything, every target property has a default binding mode associated with itself. E.g. the TextProperty of a TextBox has default binding mode as TwoWay. For the TextProperty of a TextBlock it is one way.
It is advisable that you choose the right mode as it can help you reduce the application latency especially in cases where you have large number of controls in your UI.
For more on MVVM here is an article written by me.
Is there a way to know the first time a Dependency Property is accessed through XAML binding so I can actually "render" the value of the property when needed?
I have an object (class derived from Control) that has several PointCollection Dependency Properties that may contain 100's or 1000's of points. Each property may arrange the points differently for use in different types shapes (Polyline, Polygon, etc - its more complicated then this, but you get the idea). Via a Template different XAML objects use TemplateBinding to access these properties. Since my object uses a Template I never know what XAML shapes may be in use for my object - so I never know what Properties they may or may not bind to. I'd like to only fill-in these PointCollections when they are actually needed.
Normally in .NET I'd but some logic in the Property's getter, but these are bypassed by XAML data binding.
I need a WPF AND Silverlight compatible solution.
I'd love a solution that avoids any additional complexities for the users of my object.
Update
One way that I've found to do this is using Value Converters. In my situation I had multiple point collections. There was a main dep. property that contained the usual shape of the data. Two alternate shapes were needed for reuse in other areas/contexts.
At first I had 3 dep. props. But, I could have just had one property (the usual shape) and used a value converted to transform the points into my other 2 desired shapes. Doing this I only make the one set of points in the control. The expense of transforming points to the secondary shapes is only incurred when used. Now my main control doesn't need to anticipate how data needs to look for every possible template thrown at the control - now its the template designers problem.
Update 2
Certainly INotifyPropertyChanged and regular properties are the recommended way to handle this.
You don't necessarily have to use dependency properties to enable data-binding. However, you then have to implement INotifyPropertyChanged if changes at the source should be propagated to the target of the binding. A "normal" .NET property is easy to lazy load perhaps like this:
PointCollection points
public PointCollection Points {
get {
return this.points ?? (this.points = CreatePoints());
}
}
PointCollection CreatePoints() {
// ...
}
I'm not sure how you can fit INotifyPropertyChanged into your control, but it sounds a bit strange that your control supplies data to other parts of the system. Perhaps you need to create a view-model containing the data that you then can let your control data-bind to.
If I paraphrase your question to
How do I get notified when dependency property is changed?
will this be correct? I draw this from your phrase "Normally in .NET I'd but some logic in the Property's getter, but these are bypassed by XAML data binding".
If I'm correct, then you can register your own property changed callback. It's always called. Doesn't matter who caused the change binding, style or trigger. The following code snippet is taken from MSDN Article "Dependency Property Callbacks and Validation":
public static readonly DependencyProperty CurrentReadingProperty =
DependencyProperty.Register(
"CurrentReading",
typeof(double),
typeof(Gauge),
new FrameworkPropertyMetadata(
Double.NaN,
FrameworkPropertyMetadataOptions.AffectsMeasure,
new PropertyChangedCallback(OnCurrentReadingChanged),
new CoerceValueCallback(CoerceCurrentReading)
),
new ValidateValueCallback(IsValidReading)
);
public double CurrentReading
{
get { return (double)GetValue(CurrentReadingProperty); }
set { SetValue(CurrentReadingProperty, value); }
}
Your takeaway here is OnCurrentReadingChanged() method. Hope this helps :).
I have a an object which is set to the DataContext in a Window. I have textboxes in the window which are bound to the properties on the object. There seems to be a delay however before the properties on the object are updated.
<TextBox x:Name="txtPropertyOne" Text="{Binding Path=PropertyOne,Mode=TwoWay,UpdateSourceTrigger=PropertyChanged}" />
If I change the values in a few textboxes then quickly try to access the properties to which they map, sometimes there are changes which aren't reflected in the properties of the object. I thought that was what the PropertyChanged UpdateSourceTrigger was supposed to take care of.
If I change the values in a few
textboxes then quickly try to access
the properties to which they map
I can interpret this statement in two ways:
You're trying to access the values on a background thread. In that case, you may be accessing the properties before the UI thread has had a chance to do its thing.
You're using a separate message on the UI thread to check the values. Bindings are updated at a priority lower than Send and Normal. So if your message is priority Send or Normal it will be processed before any pending binding updates.
If this doesn't answer your question, please clarify what you mean by "quickly trying to access the properties".
The basic rule of WPF Databinding is simple:
The target property must be a
dependency property, and you're
already correct, it's bound to Text
property of TextBox.
The source property can be a CLR
object (other than any derived WPF's
DependencyObject), but the object
must employ or implement its own
INotifyPropertyChanged.
Have you you already implemented INotifyPropertyChanged on your object?
I am deriving from combobox (WinForms) and am providing a new implementation for the Selectedvalue property.
It works fine as is, but any change to the selectedvalue property is not updating other controls bound to the same "binding context" to change their values accordingly.
I did try adding the BindableAttribute(true) to the property, but still it does nottrigger the change in value to the other linked controls.
The control's DataBindings.add(...) is all set up. And other controls are also bound to the same data filed on the same datasource.
Any ideas what i am doing wrong.
Have you called your base class' implementation of overridden methods? It's possible that failing to call the base class implementation is accidentally circumventing the code that fires various event plumbing.