i want to set UpdateSourceTrigger of the Binding of a PasswordBox to LostFocus or PropertyChanged dynamically.
Is there a way to bind UpdateSourceTrigger of a Binding to a DependencyProperty like this?
Password="{Binding Path=PasswordProperty, Mode=TwoWay, UpdateSourceTrigger={Binding UpdateSourceTriggerProperty}"
Kind Regards,
Andy
You can't change the UpdateSourceTrigger of an existing binding in the way you're attempting because, as Clemens points out, it is not a dependency property. Normally, you'd be able to accomplish this by using a Style with DataTriggers that replace the entire binding, but in this case you can't do that either because Password is also not a dependency property.
This later point is an intentional design choice on Microsoft's part:
When you get the Password property value, you expose the password as plain text in memory. To avoid this potential security risk, use the SecurePassword property to get the password as a SecureString.
For more of an explanation you can take a look at this great answer from the question How to bind to a PasswordBox in MVVM.
Related
I have a accustom control bound to a model class. So if any change in UI for textbox it updates ViewModel.model instance. but it doesnot work the other way. What is the necessary thing I need to look for? or troubleshoot steps pls.
Thanks.
You mean the value is displayed in the Textbox but a new typed value isn't?
If so you need to set two way binding on the Textbox binding:
<Textbox Text={Binding myTextProperty, Mode="TwoWay", UpdateSourceTrigger="ProprtyChanged"/>
This will enable both read & write functionality to your binding.
As #Ganesh says, you also need to make sure you're implementing the INotifyPropertyChanged interface in your ViewModel.
Is it possible to write something like this
<TextBlock Text="{Binding Path=TextSource, StringFormat='{Binding Path=StringFormat}' }"
Or the single way is to have three properties: one for some value and other for string presentation of this value, third for format string. In this case TextBox binds with string representation of value. String presentation changes when format string changes.
Yes, it is possible in general and no for your case it is not possible because StringFormat is not Dependency Property.
Binding only works on Dependency Properties.
If you wish that to work create a resource dictionary of type Freezable and let it inherit the actual DataContext. Futhermore use StaticResource extension to set StringFormat in Binding.
StringFormat is not DependencyProperty but it doest accept {StaticResource someKey}.
It's a workaround. But it would work.
Another alternative solution would be attached property.
Attached properties are bindable. You would need to listen to property changed event of your attached property and change the StringFormat inside the handler.
I'm looking for a solution and/or the rationality behind why a Binding instance is shared within a DataTemplate. This ultimately comes down to the fact that within a DataTemplate, there's seemingly no way to force a new instance of a Binding on a DependencyProperty for each control generated. That is probably a fair and good assumption in all cases except when there are ValidationRules representing something specific about the instance of that control.
To elaborate (I can provide code, but I don't believe it's necessary), I use a DependencyPropertyDescriptor on IsEnabled to update one or more ValidationRules that belong to a TextBox.Text Binding, DatePicker.Text Binding, or a ComboBox.SelectedValue Binding, etc. The idea is that validation will be different or undesired when a control is not enabled.
Because of this, the ValidationRule's state of IsEnabled is specific to the individual control and because the ValidationRule Collection is a part of the Binding and the Binding instance is being shared - each control that ends up sharing that binding will update/override the previous IsEnabled value that was applied by the previously generated control's IsEnabled value.
IsEnabled is only one of at least two properties in the ValidationRule (another custom IsRequired DependencyProperty) that represent the state of the control to which the Binding is applied. When working outside of a DataTemplate (IE: The Binding instance is not shared), this works very well and ignores/alters the validation logic based on the state of the control. I'm not closed off to alternatives but do feel this has been (this issue aside) a very flexible and dynamic option that allows the Binding instance ValidationRule's and the control-changed state of the Rules to evolve effortlessly. This has also allowed me to avoid other obvious but much uglier options such as creating several Bindings, each representing one of the combinations of the ValidationRule's control properties and switching the whole binding out at the time the DependencyPropertyDescriptor fires. shivers
Any thoughts are MUCH appreciated!
I suggest you to use x:Shared attribute in the DataTemplate definition.
<DataTemplate x:Key="DataTemplateKey" DataType="{x:Type YourType}" x:Shared="False">
...
</DataTemplate>
Since you use it WPF will create a new DataTemplate instance on every request.
I have a property on a Silverlight control that a ViewModel wants to bind to. The ViewModel need to told of changes to the property NOT the other way around
Syntax like
<MyControl ViewPort="{Binding VMProperty}"/>
Declares ViewPort as the Target, in this instance ViewPort is the source of the data. I know I could make it TwoWay binding but that just seems wrong when i simply want one way but in the other direction.
Besides I do not want to make the property on the control a DependencyProperty because I do not want that property settable and I do not beleive that Silverlight supports read only dependency properties.
Is there a different way of setting up the Binding?
TIA
Pat Long
Maybe this works?
http://forums.silverlight.net/forums/p/141042/315359.aspx#315359
{Binding ElementName=TextBox1, Path=Text, Mode=TwoWay ,UpdateSourceTrigger=Explicit}
Normally when you want a databound control to 'update,' you use the "PropertyChanged" event to signal to the interface that the data has changed behind the scenes.
For instance, you could have a textblock that is bound to the datacontext with a property "DisplayText"
<TextBlock Text="{Binding Path=DisplayText}"/>
From here, if the DataContext raises the PropertyChanged event with PropertyName "DisplayText," then this textblock's text should update (assuming you didn't change the Mode of the binding).
However, I have a more complicated binding that uses many properties off of the datacontext to determine the final look and feel of the control. To accomplish this, I bind directly to the datacontext and use a converter. In this case I am working with an image source.
<Image Source="{Binding Converter={StaticResource ImageConverter}}"/>
As you can see, I use a {Binding} with no path to bind directly to the datacontext, and I use an ImageConverter to select the image I'm looking for. But now I have no way (that I know of) to tell that binding to update. I tried raising the propertychanged event with "." as the propertyname, which did not work.
Is this possible? Do I have to wrap up the converting logic into a property that the binding can attach to, or is there a way to tell the binding to refresh (without explicitly refreshing the binding)?
Any help would be greatly appreciated.
Thanks!
-Adam
The workaround here was to add a property to my object (to be used as the datacontext) called "Self" , which simply returned
public Object Self { get { return this; }}
Then in the binding I used this property:
<Image Source="{Binding Path=Self, Converter={StaticResource ImageConverter}}"/>
Then when I call
PropertyChanged(this, new PropertyChangedEventArgs("Self"))
it works like a charm.
Thanks all.
I don't believe there is a way of accomplishing exactly what you need with your current converter. As you mentioned, you could do the calculation in your ViewModel, or you could change your converter into an IMulitValueConverter.
From your specific scenario (the converter tied to a ViewModel class, and a few of its properties), I would lean towards implementing the logic in the ViewModel.
Hmm, you don't show the full implementation. But I think it should update, if the value bound to the GUI provides the PropertyChanged-Event.
Regards