`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.
- Don't log an error when the target for the root ExpressionNode is
null. This is usually because the `DataContext` hasn't been set up yet
and it spewed a load of useless error messages.
- Add a Description field to `ExpressionObserver` that can be used in
the case of e.g. #control bindings to record the whole expression (with
the "#control" part) rather than just the part tracked by the
`ExpressionObserver`.
Can't remember why this was there but it was wrong anway - it wasn't
actually removing the items from the presenter panel. Doesn't seem to
break any unit tests so hope for the best...
This meant that if a control with a template was removed, when it gets
re-added all of the template children's bindings are broken. The logic
to clear the TemplatedParent when applying a new template is in
TemplatedControl.ApplyTemplate - this is where it should be done.
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.
If a TextBox is e.g. bound to an int and the user types "02" then the
TextBox text should be "02" - not the value that comes back from the
binding which will be "2".
Doing a `Publish().Refcount()` caches the latest value so it can be sent
to subsequent subscribers, and this causes a leak. Convert the value
to/from `WeakReference` for that part.
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.
Introduced in a refactoring a few commits ago where I saw code that
looked wrong. It wasn't wrong, it's just the mechanism is a little
unintuitive. Added a comment explaining the reasoning.
Steven Kirk