I don't understand what bindable properties offer more than normal ones. Perhaps the PropertyChanged event? But I guess you could write in your normal property setter whatever you'd write in the PropertyChanged event. One simple example with these two might make it click in my head. Thanks!
from the docs
The purpose of bindable properties is to provide a property system
that supports data binding, styles, templates, and values set through
parent-child relationships. In addition, bindable properties can
provide default values, validation of property values, and callbacks
that monitor property changes.
Related
Right. So moving from WPF to UWP, I'm trying to use x:Bind to get compile-time benefits. Simple scenarios work fine; however I have found a number of issues that I was not able to solve. They are all related, so I thought I'd post them in one place:
I haven't been able to make Intellisense work with x:Bind. I have set DataContext (as well as d:DataContext just as we do in WPF) both in XAML and in the constructor, but it won't show members no matter what. Has anyone done this successfully?
Then I read somewhere that in UWP, DataContext is always set to Page's code-behind (really??) and that I need to define a ViewModel type property in the code-behind and then use that property in x:Bind. Is this correct? I tried it and it works but gives rise to the next question.
If I define a property of ViewModel type in Page's code-behind, Any sub-properties that raise PropertyChanged notifications do not update the UI. For example, if the code-behind property is named Game (of type GameVM) and there is a public property in GameVM named Player (of type GamePlayer), and in turn GamePlayer contains a property named Name, the x:Bind path will look like {x:Bind Path=Game.Player.Name}. But if I do this, any change notifications raised from within Name property do not update Page's UI.
One alternate I tried was to listen to PropertyChanged at each level and then bubble it up the hierarchy, but that hasn't worked. Even if it does, doing this seems a bit too much work. In WPF sub-properties like Game.Player.Name work properly without having to doing property change bubbling. Or am I missing something?
Right. After playing with it for a few days and searching numerous references, here are my findings:
{x:Bind} lacks design-time support. The feature is on the wishlist though. You may want to upvote it there.
(The new version of Visual Studio 15.4.4 does support Intellisense in {x:Bind}in the required way.)
{x:Bind} uses code-behind as its DataContext. So you need to define a public property of your ViewModel type in the code-behind and then use it in your {x:Bind} path.
As pointed out by IInspectable, the default mode for {x:Bind} is OneTime, unlike {Binding} which uses OneWay or TwoWay in almost all cases. So you need to explicitly specify Mode in your binding. People coming from WPF should take special care of it.
Sub-properties that implement notification change work perfectly fine in {x:Bind}. There is no need of bubbling these notifications upwards in the property hierarchy. The problem I was facing (#3 in the question) was because my sub-property was of type List<T>. I changed it to ObservableCollection<T> and it started working.
Hope this works somebody down the road.
Well as a beginner, the only question I can answer for you is the first one. Intellisense does not work inside the {x:Bind}. The members are never shown there in UWP for some unknown reasons. As for the next two questions of yours, I am still working on them.
I ran into the same challenge that you have seen. In my experience, in order to create the compile-time binding and have it update with custom objects as properties, the Page class seems to need to know about the data context and custom objects... all you need to do is reference them in the code behind, and then bind to them in the XAML. This creates the code generation objects it needs.
For example, I have a viewmodel, CustomerViewModel that is bound in XAML. That viewmodel also has a property of type IGuest. In order to use the guest object and have it update properly, I came up with this in the code behind...
CustomerViewModel vm
{
get
{
return (CustomerViewModel)DataContext;
}
}
IGuest g
{
get
{
return vm.CurrentGuest;
}
}
public CartGuestControl()
{
this.InitializeComponent();
}
You don't need to assign any of the UI data contexts from the code behind... simply reference the datacontext that is bound in XAML. When binding to any straight viewmodel properties, I use {x:Bind Path=vm.IsEditing, Mode=OneWay}. For binding to any of the guest properties, it looks like this, {x:Bind Path=g.FirstName, Mode=TwoWay}. You could do something like this for your Player object.
I have run into times where x:Bind simply won't do what I expect it to do no matter what I try. This can usually be solved by breaking things out into smaller user controls with more specific data contexts or by using "regular" Binding.
I'm programming a bunch of WPF usercontrols (not CommonControls!) using an Interface for the common properties like the alignments or the Content (depending on the control; TextBox returns the Text, and Label the Content per example).
Now i get to controls like the Checkbox, which have the not so common property IsChecked.
Do i have to implement this property by the Interface or is it allowed to program it in the usercontrol itself?
I hope you're talking about binding a property to a view model or directly mentioning the property value in the xaml itself.
It actually depends upon your requirement. We normally bind a property value to a view model or code behind when that property needs to be checked by certain conditions and then to be set. If you're sure of the property's value, you can set it in xaml itself.
For example if you want to set a textbox's IsEnabled property, and you're sure that the text box is always editable. Then set it as true in xaml itself. But if you're text box need to be enabled during an event is handled, bind it to a property in view model and set it to true during the event trigger.
Okay, i have to guess it was a dumb question.
But after eight hours you don't know anymore, if you're Hillary or Donald.
The answer is: An Interface can inherit from another and implement all members from the "parent" interface.
In Flex (AS3) you can do neat things where you bind a property to an expression/variable/object. e.g. button.enabled = {!obj.name.empty} It makes for very neat GUI validation amongst other things.
I don't see any such facility in Visual Studio GUI designer but wondered if this sort of functionality exists in .Net/C# and if so, to what extent?
I don't see any such facility in Visual Studio GUI designer
In fact there is. Select the form/control in the designer, then go to Properties window and expand the (DataBindings) category. You'll see a couple properties there, and more if you click the (Advanced) item.
to what extent?
It could only bind to a property (no expressions are supported). To make it work, the object providing the property must support property change notification. The standard way is implementing INotifyPropertyChanged interface, but there are also other mechanisms - IBindingListimplementation providing ListChanged event, object providing event named PropertyNameChanged for a PropertyName etc.
As I mentioned, standartly you can bind only to properties. However, at runtime with some helpers you can really bind to a method or expression. I've already provided examples of doing that in the following threads Button enable and disable on text changed event, Exchange UserControls on a Form with data-binding, Custom WinForms data binding with converter not working on nullable type (double?), .Net WinForms design to sync Data and Controls for a single item data binding, and my own question Cross tabular data binding in WPF for more complex scenarios.
Contrary to what some WPF-ers say, there are no WF limits when binding to a custom objects/collections. The only limits are when binding to other control properties because control property notification pattern is not strictly followed like in WPF where it is by design.
How can I find and access to Elements which are bind to an object in XAML ?
Edit : Let's say I have a EmployeeViewModel which is assigned to EmployeeView's DataContext and a EmployeeModel inside my EmployeeViewModel, I want to know which properties of my model bounded to View's Framework Elements (Controls) also I want to have an access to each control bounded to my model properties.
UPDATE: In light of the question being clarified by SaberAmani in that he is trying to add validation to his models and show a validation summary..see the links below.
http://msdn.microsoft.com/en-us/magazine/ff714593.aspx
http://codeblitz.wordpress.com/2009/05/12/wpf-validation-summary-control/
http://wpfvalidation.codeplex.com/
http://f10andf11.blogspot.co.uk/2012/02/wpf-validation-summary-control.html
For reference for people that want to discover Bindings:
You don't mention if your XAML is in WPF, Silverlight, Metro or Phone7 (thus you may be more restricted in what you can do).
There seem to be a few possible ways to do what you want:
Reflection
MarkupObject / MarkupWriter
TypeDescriptor+DependencyPropertyDescriptor
Custom Binding Markup Extension
Take a look at this link.
http://blog.spencen.com/2008/05/02/how-to-get-a-list-of-bindings-in-wpf.aspx
He uses reflection and suggests this is the classical way to do it...but also mentions MarkupWriter as another possibility. NOTE: the reflection method doesn't discover Attached Properties which may have bindings.
Here are some links that use MarkupWriter...this would allow you to discover the attached properties.
http://www.codeproject.com/Articles/21139/An-XAML-Serializer-Preserving-Bindings
http://blogs.msdn.com/b/marlat/archive/2009/05/24/getbindingexpression-a-good-way-to-iterate-over-all-dependency-properties-in-visual-tree-in-silverlight-3.aspx
Related links:
Retrieve all Data Bindings from WPF Window
Getting list of all dependency/attached properties of an Object
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/580234cb-e870-4af1-9a91-3e3ba118c89c
you could use reflection to loop through properties and use FrameworkElement.GetBindingExpression on each property to build, for a given Framework element, all its bindings.
http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.getbindingexpression
I have an ObservableCollection that's binded to a WPF ListView, and all the values appear correct. But how can I get a notification when something that has a 2-way binding changes?
Should I use INotifyPropertyChanged just like in Winforms? Or are there better practices to do these?
I saw some people suggesting using dependency properties online, but not sure if that's what should do.
If the class I want to add a property is a DependencyObject, I generally add a DependencyProperty. If the class is a POCO (plain old clr objects), then I implement INotifyPropertyChanged.
In generall, all my business objects are POCOs and therefore I use INotifyPropertyChanged. In the WPF world, I mostly use DependencyObjects (view models, custom controls, UserControls...) and therefore they are DependencyProperties. An exception are ViewModels representing items (to be used as items in an items source). In this case I think DependencyProperties are not very practical (Because Equals() and GetHashCode() of DependencyObjects are sealed and DependencyObject is thread-dependent).
If your class already is a DependencyObject, using DependencyProperties may give you some nice advantages: You don't have to back every value, a powerfull inheritance system, default-values, property changed callbacks per property, value coercion ... (I like DependencyProperties probably more than other people them like :)
Conclusion:
Based on the title of your question: How to get notified when something changes in a WPF window?, my way would be to add a DependencyProperty and not a clr-property because the Window is a DependencyObject. By the way, Visual Studio has a nice Snippet to create DependencyProperties.
There are really two scenarios:
1) Notifying the UI when a piece of data changes-either in the ViewModel or a Model that is bound to some UI elements (usually due to a data binding). In this scenario you'd use INotifyPropertyChanged.
Example: you have a Person object that binds it's Name to a TextBox. Person needs to implement INotifyPropertyChanged and the appropriate code needs to be attached to the Name Property's setter.
2) Creating custom UI elements where you'd want data to be bound. In this case, you'd use custom dependency properties.
Example: you have a custom UI element that spins when a certain condition is met. So you create an IsSpinning dependency property that you can bind to your ViewModel's IsLoading property. The custom control then uses the IsSpinning property to modify its behavior.
I hope that was clear...
You are right. You can use INotifyPropertyChanged or you can implement dependency properties. Personally I prefer INotifyPropertyChanged, it's more light and easyer to implement than dependency property.
I've generally used INotifyPropertyChanged for my data objects.
DependencyProperties can only be implemented on framework elements I believe.
Edit: I take that back... DependencyProperties can only be implemented on DependencyObjects (A FrameworkElement is an example of that as it derives from UIElement which derives from Visual which derives from DependencyObject).
If you have a UserControl, you may wish to implement a Dependency Property so you can Bind that Property (in XAML) to some other property. You could not do this scenario with INotifyPropertyChanged.