Rather than just use a standard `Binding`, make `TemplateBinding` a lightweight binding in the case where the binding is simply to a property on the templated parent.
`TemplateBinding_With_Null_Path_Works` is a failing test for #1303, also added a passing test for the same thing with `Binding`: `Binding_With_Null_Path_Works`.
Previously it wasn't clear which constructor on `InstancedBinding` must be called for a particular binding mode. Refactored the constructors:
- We now have a single public ctor which takes an `ISubject`, as a subject can be used for all binding modes.
- Instanced bindings with other sources such as single values and `IObservables` are now constructed via static methods which only allow the correct sources for that binding mode
Update Rx.Net dependency to match reactiveui's dependency on Rx.
Removed ReactiveUI dependeny in BindingTests.
Updated BindingTest sample to use the new reactiveui APIs.
Update samples to use current ReactiveUI APIs.
Fixed bug I introduced into tests.
Remove RxUI submodule info from .gitmodules
To do this needed to change behavior a little in that now binding errors update the target. Previously in the case of a binding error at the first node in the binding chain, we were converting the `BindingNotification` to `UnsetValue` which had the effect of updating the target value. Now we're passing the `BindingNotification` back, we need to make sure this happens. I believe this is the right thing to do as the behavior should be the same no matter where in the binding chain the error occurs. Data validation errors continue to not update the target.
`ExpressionSubject` wasn't a good name as the important thing it isn't
convert an `ExpressionObserver` into an `ISubject`. The important thing
it does is insert an `IValueConverter` into the pipeline.
This reverts commit 57e646583f.
For TextBox there can be 2 bindings to Text: one which is the binding to the
view model which should have data validation enabled, and another binding to
the TextPresenter in the template which should not have data validation
enabled, or it will override the view model data validation. For this we need
to be able to distinguish between the two and so bindings with data validation
enabled need to always send BindingNotifications.
Conflicts:
src/Avalonia.Base/AvaloniaObject.cs
tests/Avalonia.Markup.Xaml.UnitTests/Data/BindingTests_Validation.cs
We're going to say that for the moment only direct properties handle
data validation. This gets around a few thorny issues with data
validation on styled properties.
Steven Kirk
José Pedro
Steven Kirk
Jeremy Koritzinsky
Wiesław Šoltés
Steven Kirk