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
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.
Previously we ensured that `AvaloniaObject.SetValue` was run on the main
thread. This makes sure that `GetValue`, `IsSet` and `ClearValue` are
also run on the main thread. Unit testing this turned out to be more
complicated than expected, because `Dispatcher` keeps a hold of a
reference to the first `IPlatformThreadingInterface` it sees, so made
`UnitTestApplication` able to notify `Dispatcher` that it should update
its services.
OneTime bindings were failing in BindingTest because the initial binding
error was being counted as the single value to transfer. Don't do this
with OneTime bindings - only transfer valid values.
This is needed so that things like the following can be done:
<TreeView>
<TreeView.Styles>
<Style Selector="TreeViewItem">
<Setter Property="IsExpanded" Value="{Binding IsExpanded}"/>
</Style>
</TreeView.Styles>
<TreeView>
(At the moment we have TreeDataTemplate.IsExpanded but this isn't good
enough: it only supports setting IsExpanded on creation of the item with
no binding.)
With this commit, setters can now contain bindings, but they aren't yet
applied correctly. As part of this commit, classes related to binding
have been moved to the Perspex.Data namespace.
Described by XamlBindingTest.Should_Not_Write_To_Old_DataContext.
Problem still remains with ListBox.SelectedItems however, that's going
to require something more.