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 speeds up the common path of no data validation: this way we don't
need to get the metadata unless a binding notification is received. This
means that if a binding with data validation is assigned to a property
that isn't interested then UpdateDataValidation will be called, but the
control should just ignore it.
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.
From Avalonia.Base.UnitTests to Avalonia.LeakTests - the test was
failing on mono on OSX and I can't work out why. Leak tests don't
currently get run on mono CI.
Nikita Tsukanov
Steven Kirk
donandren
Jeremy Koritzinsky
Wiesław Šoltés
Steven Kirk