I'm a bit stuck on this one. Clearing the binding of the TextProperty of some TextBox that is not part of a DataTemplate works fine. But when the TextBox is part of a DataTemplate, clearing the binding seems to be a no-op as shown in the snip below. The watch value is true even after the binding is presumably cleared:
Is this by design? If not, what am I doing wrong?
Here is the MSDN documentation of ClearBinding(...): http://msdn.microsoft.com/en-us/library/system.windows.data.bindingoperations.clearbinding
I found this MSDN post that covers the issue. While it seems to leave the issue without a real explanation, it does provide a workaround that seems to work just fine.
I replace the ClearBinding invocation with replacing the binding with some dummy value:
AssociatedObject.SetBinding(TextBox.TextProperty, "dummy");
Now it seems that this will break when the control is not from a DataTemplate. So to work-around that, and so cover TextBoxes from DataTemplate and otherwise, I now do this:
BindingOperations.ClearBinding(AssociatedObject, TextBox.TextProperty);
if (BindingOperations.IsDataBound(AssociatedObject, TextBox.TextProperty))
AssociatedObject.SetBinding(TextBox.TextProperty, "dummy");
And voila, the binding is "severed" and so my watermark seems to work just fine now.
Not sure if this would work (didn't try), but please try using BindingOperations.ClearAllBindings() method as stated in this excerpt from MSDN (see below how MSDN refers to Data Template):
Clearing the binding removes the binding so that the value of the
dependency property is changed to whatever it would have been without
the binding. This value could be a default value, an inherited value,
or a value from a data template binding.
To clear bindings from all possible properties on an object, use
ClearAllBindings.
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 have a TextBox bound to the Entity Framework object User. Works fine. But now, when I change the User object to the new User.CreateUser(0, ...) or null, TextBox doesn't change.
Why?
Best regards, James
pls post your binding and your datacontext, otherwise its hard to say whats wrong. i could just assume that INotifyPropertyChanged is not implemented.
You have to make sure that the binding hooks in at right level, not all changes are observed by the binding engine, e.g. if you only specify the Source that is identical to assigning the object referenced by the source, the binding will look for the PropertyChanged event on the source to update itself if you bind to a property using the Path, however it will never know if the source is swapped out.
If you bind to the User using the path this is not your issue, just what exactly is wrong is not inferable (for me, that is) from your question alone, you should probably post some code.
I've got a strange problem - binding created through XAML (both ways by markup extension or normal) isn't working(BindingOperations.IsDataBound returns false and in fact there is no Binding object created). When I do literally the same from code everything is working perfectly.
One more thing is that the Binding in XAML is created in a DataTemplate - what's funny about that when I use the DataTemplate for the first time it fails, then I fix it from code (add binding to specific objects) and while adding more objects to the collection the binding set in XAML just works. If I try to remove all the objects from the collection and then add a new one the binding fails once again.
In reality this is a shortened version of another of my questions. For details please refer to:
WPF Debugging AvalonEdit binding to Document property
Sorry for doing it this way, but there's no answer and it's probably too long for anybody to read.
-
Is there any exception traced in Output window? WPF usually complains there instead of just failing the program.
The problem may be related to your use of IsAsync and some problem with the target property's handling of an invalid result. You might want to try getting rid of the IsAsync parameter or using a PriorityBinding to set a safer default to use while waiting for the async loading to complete.
Does it make sense that if the Text on a TextBox is databound to a property using the twoway mode and I set the Text to something, it should update the property? My property gets updated when I type inside the control, but not when I set the value in code.
I would say it makes no sense to modify a bound Text property directly. Your code should be setting the other end of the binding and allowing the binding to update the control.
If the bound object is updated when the Text property is set then special case code would be needed to detect when such an assignent is the result of the bound object changing for other reasons. Otherwise you would end up with an infinite loop.
You shouldn't set the .Text value of the textbox... set the value of the property it's binding to. :)
I'd encourage you to read more about the Model-View-ViewModel method for designing your views. It keeps a clear separation of concerns when doing this kind of work. The reason you are seeing this "bug" regarding focus causing the binding to refresh is because most of the time this kind of thing is not appropriate.
Here's a pretty good video introduction to MVVM: MVVM on Channel 9
This is because it only commits the data when the textbox loses focus. Here is a question that is somewhat related that eludes to this.
Is there a way to get WPF to automatically apply a Converter to all bindings of a specific type?
I've seen this question, but it covers a different case (localisation) and thus has no satisfying answers.
My problem: I've got model classes containing Commands, which I would like to bind to WPF Commands. Since the model classes are toolkit-independent, I cannot implement WPF's ICommand there. Instead I have a CommandConverter which wraps CommandModels into WPF ICommands:
<Button Command="{Binding MyCommand, Converter={StaticResource CommandConverter}}" />
This works quite well, except that it is easy to forget about the Converter= and WPF doesn't give any indication that the binding failed.
My question is now: Is there a possibility to force WPF to always a apply a converter to specific types of bindings? Or, alternatively, how can I get WPF to give me proper errors when a Command binding fails?
I don't think you can without either sub-classing Button (you probably don't want to do this), or defining your own attached property and using a TypeConverter attribute on it.
If you want to go with using a default converter via the TypeConverter attribute on a new attached property, you can look at Rob Relyea's informative post here, or MSDN here.
While I've never done it, would it be possible to define a custom Markup Extension? That should cause the value to be sent to your class that implements the Markup Extension, and then from there you can return an ICommand that the Command property is expecting.
As I said, I've never created one my self, but a Google Search seems to bring up a few articles on how to do it.
Check the debug output window. Normally you get to see the binding errors there.