When a `TemplateBinding` is used as a `Setter.Value`, then we need to make sure we don't use the `TemplateBinding` itself as the binding because this can cause a memory leak.
Replace `IRequiresTemplateInSetter` with `ISetterValue` which can be used to require a template in the setter for `Control` and can also be used to notify `TemplateBinding` that it's in a setter and so should always clone itself.
Fixes#2420
This is a relic from when we were targeting a PCL profile that didn't have `System.ComponentModel.ISupportInitialize`. Now that we have that, use it instead.
Don't notify a non-inheritance child that the data context has begun changing, because it won't receive the accompanying end change notification.
Fixes#1245.
When a data context changes, it should be notified to all descendant controls who inherit the data context. This allows the `SelectingItemsControl` to defer setting the selected item until the `DataContext` has changed for the whole tree.
Renamed `OnDataContextChanging`/`OnDataContextChanged` to `OnDataContextBeginUpdate`/`OnDataContextEndUpdate` because `DataContextChanged` is now called from the property changed notification.
Fixes#507.
Previously, if the user overrode `OnAttachedToLogicalTree` or `OnDetachedFromLogicalTree` and forgot to call the base implementation, the events wouldn't be raised. It's very important that these events get raised so moved the code to raise them to `OnAttachedToLogicalTreeCore`/`OnDetachedFromLogicalTreeCore`.
Added an `IDataTemplateHost` interface with a `IsDataTemplatesInitialized` property to prevent the need for allocating empty `DataTemplates` collections for many controls.
If we have e.g. a named UserControl in a window then we want that
control to be findable by name from the Window, so register with both
name scopes. This differs from WPF's behavior in that XAML manually
registers controls with name scopes based on the XAML file in which the
name attribute appears, but we're trying to avoid XAML magic in Avalonia
in order to made code-created UIs easy. This will cause problems if a
UserControl declares a name in its XAML and that control is included
multiple times in a parent control
(as the name will be duplicated), however at the moment I'm fine with
saying "don't do that".
Fixes#829.
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.
Steven Kirk
Benedikt Stebner
Max Katz
Dan Walmsley
amwx
Steven Kirk
Miha Markič
Jeremy Koritzinsky
Goldy
brandonhood
Nikita Tsukanov
donandren