Binding OneWayToSource with OneTime initalization of target - wpf

Question

I have a DataGrid with editable cells bound to their respective values in the view model of the respective items.
Initially, the data is loaded and displayed to the user, who can then edit the data in the grid.
Binding is working as it should (in my case with UpdateSourceTrigger=OnPropertyChanged), but due to conversions between double (view model) and string (UI), a TwoWay binding would cause annoying UI bugs like making decimal separators or zeros after a decimal point disappear when typed by the user.
Two faulty solutions are:
Making the property a string in the view model, and doing the necessary conversions inside the view model.
Problem: brings me a strange problem of incompatible cultures between the UI and the view model (and I don't expect the view model to know the UI's culture)
Using a OneWayToSource binding. This eliminates all UI bugs as the VM stops sending back parsed and reconverted values.
Problem: I can't (or don't know how to) initialize the values in the grid with the loaded data.
So, can I somehow use a OneWayToSource binding "after" a OneTime binding, or somehow sum the two?
I tried to bind FallbackValue and TargetNullValue to the source values, but they don't accept bindings.

Answer 1

The decimal place disappearing is a "feature" they introduced whilst trying to fix something else. I thought it was .Net 4.0 this was introduced and people started noticing it was a breaking change but the documentation seems to imply .Net 4.5.
It usually occurs because you set updatesourcetrigger=propertychanged.
The simple fix is often to just remove that.
Because
, UpdateSourceTrigger=LostFocus
Is the default behaviour for textbox text binding.
Alternatively, you could experiment with KeepTextBoxDisplaySynchronizedWithTextProperty
https://msdn.microsoft.com/en-us/library/system.windows.frameworkcompatibilitypreferences.keeptextboxdisplaysynchronizedwithtextproperty(v=vs.110).aspx
public MainWindow()
{
FrameworkCompatibilityPreferences.KeepTextBoxDisplaySynchronizedWithTextProperty = false;
InitializeComponent();
}
You can set that in Mainwindow before anything is displayed.

Answer 2

I found out a hacky workaround that involves using two properties, the original and a string dedicated to the user for smooth behavior. Use a specific converter for that purpose. (I think I'll adopt this as a pattern for future cases)
This works for cases where the view model does not change the property, only the user changes the property. (If you want a truly two way interaction where the view model also changes the property, you need to set the string property to null whenever you need to change the property)
In the view model:
The differences from a standard code are:
adding a string property without logic
adding a notification for this property when the original property changes
Code:
private double? _TheProperty;
public double? TheProperty { get { return _TheProperty ; } set { SetTheProperty (value); } }
public string ThePropertyUserString { get; set; } //for UI only!!! Don't change via code
private void SetTheProperty(double? value)
{
if (value == null)
{
//implement validation errors if necessary
//using IDataErrorInfo and ValidatesOnDataErrors
//this type of validation is the only I found that helps enabling/disabling command buttons
}
//do your logic
_TheProperty = value;
//notify
if (PropertyChanged != null)
{
PropertyChanged("TheProperty", ...);
PropertyChanged("ThePropertyUserString", ...);
}
}
In the XAML:
<TextBox Style="{StaticResource ErrorStyle}">
<TextBox.Text>
<MultiBinding UpdateSourceTrigger="PropertyChanged"
Mode="TwoWay"
Converter="{StaticResource DoubleUserStringConverter}">
<Binding Path="TheProperty" ValidatesOnDataErrors="True"/>
<Binding Path="ThePropertyUserString"/>
/MultiBinding>
</TextBox.Text>
</TextBox>
The converter:
/// <summary>
/// multibinding, first binding is double? and second is string, both representing the same value
/// the double? value is for the viewmodel to use as normally intended
/// the string value is for the user not to have ui bugs
/// </summary>
class DoubleUserStringConverter : IMultiValueConverter
{
private OriginalConverterYouWanted converter;
public DoubleUserStringConverter()
{
converter = new OriginalConverterYouWanted(); //single binding, not multi
//for types "double" in the view model and "string" in the UI
//in case of invalid strings, the double value sent to UI is null
}
//from view model to UI:
public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture)
{
if (values[1] == null) //null string means UI initialization, use double
return converter.Convert(values[0], targetType, parameter, culture);
else
return values[1]; //in the rest of the time, send user string to UI
}
//from UI to view model
public object[] ConvertBack(object value, Type[] targetTypes,
object parameter, CultureInfo culture)
{
return new object[] {
converter.ConvertBack(value, targetTypes[0], parameter, culture), //can be null
value //string is always sent as is, no changes to what the user types
};
}
}