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.
Related
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.
I have a view model property that is set to runtime objects. I want to trigger an animation whenever this property changes, so I was planning to use DataTrigger. However, DataTrigger obviously has the requirement for a Value property--one that I don't know at design-time.
Is there a built in way to trigger an animation whenever a value changes, regardless of what it changes into?
I saw this question but I was wondering if there was anyway to do it purely in XAML. Otherwise I figure I could probably fire an event from my View Model whenever the property changes and listen to that.
One method would be to create a User Control with a dependency property and then bind both of your other properties to that i.e. one at compile time and the other at runtime. Alternatively you could use an Attached Behaviour to do the same thing.
Can add a boolean property and trigger the animation based on the bool property. Whenever the original property changes, set and reset the boolean property so that it triggers the animation and also goes back to default value for next notification.
In my WPF application, my Viewmodel has a boolean property IsOwnerOf and a string property Title. If IsOwner==false, I want a TextBlock displaying the Title (because if you're not the owner, you should not be able to edit it) and if IsOwner==true, I want a TextBox displaying Title - obviously at the same place in the view.
Also I don't want to do it codebehind since I follow the MVVM pattern. Thought about Style.Triggers, but with them I can only influence attributes of an element, not the element type itself, or can I?
EDIT:
Practically the answers below regarding triggering Visibility or IsReadOnly work, but I still would like to see a conceptually better answer! What if I replace the TextBox resp. TextBlock by elements that don't have these convenient properties? There must be a better way than creating both and hiding one of them, that just doesn't sound right...
The easiest option is to always drop a TextBox and bind it's IsEnabled or IsReadOnly property to the IsOwner flag.
You can also use a DataTemplateSelector to achieve this.
You can use triggers to change the Visibility of your TextBlock and TextBox using a BooleanToVisibilityConverter
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.
I need to be able to get and set the textbox's text, but I don't want every single change in the textbox's text to update a string in my viewmodel. It seems to me that binding a string to the textbox's text property would be nearly as inefficient as updating a string on a textbox's textchanged event or am I wrong?
The default UpdateSourceTrigger for bindings to TextBox.Text is LostFocus, which means that the string in your viewmodel is only updated when the TextBox is left.
Of course, if you do something like this
<TextBox Text="{Binding Path=ItemName, UpdateSourceTrigger=PropertyChanged}" />
then your string will be updated every time something changes in the text box. So, yes, it would be "nearly as inefficient as updating a string on a textbox's textchanged event".
Still, I don't see a real-world problem here: Even if you have a very fast typing user, updating a string in memory is not an operation that takes a terrible amount of time. In fact, processing the user input by the TextBox itself (showing the characters typed, scrolling the text to the left if the end of the box is reached, etc.) also needs quite a bit of processing, so I don't think updating your string creates such an unreasonable additional burden.
I would think it really depends what you define as efficient. To me, being able to declare a two-way binding declaratively on the XAML level is a lot more efficient than handling the text changed event and attaching myself to the property changed of a view model and copying stuff back and forth.
Why would I do that?
Apart from that, the default binding behaviour is on focus lost...