Binding errors are being logged even before DataContext is set
#5762
Assignees
Labels
Comments
|
Yeah I've noticed the binding errors in However I've not been able to reproduce this with controls. As you can see from the above link they should only log binding errors once they're attached to a logical or visual tree. |
|
I believe I am seeing this with Desktop
|
|
I've taken more of a look into this, and the problem is that while in One solution might be to on a case-by-case basis add to Ideally we'd be able to detect when a binding is using I think this one will either have to be tackled as part of a general overhaul of our binding infrastructure, or we can use the hack mentioned above. Thoughts? |
|
I do not just get this for |
|
@MarchingCube do you remember how to disable them? |
This was referenced Oct 18, 2022
Closed
This was referenced Jan 28, 2023
You can implement ILogSink and set property Logger.Sink with your custom logger sink implementation. In which you can filter log messages. |
|
I updated to Avalonia 11.0.6 (from the 0.x versions) and I noticed that on shutdown I now get a bunch of: Putting a breakpoint when that is printed I was able to dig in and find out that it seems this is caused when the controls are removed. Most of the callstack: I've written some custom animations, but this might be from the default progress bar functionality. |
|
@hhyyrylainen can you try this PR? #13970 |
|
I might be able to but I haven't tried compiling Avalonia myself at all so I'd need to figure that out. I've relied entirely on the nuget packages so far. |
|
no need to compile it on your own. We have previews on all PRs: #13970 (comment) |
|
Oh that's very nice. I gave a quick spin after changing all Avalonia package versions to I didn't do a full rigorous test but the basic functionality of my app didn't break with the changes. Though for the other issue I just reported it seems this causes slightly more error prints on shutdown ( |
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 29, 2024
* Update ncrunch config. * WIP: Benchmarks * Initial refactor of binding infrastructure. - `ExpressionObserver` has been removed and its functionality merged with `BindingExpression` - `BindingExpression` handles all types of `BindingMode` itself; doesn't require `BindingOperations.Apply` to set up a separate observable for `TwoWay/`OneWayToSource` bindings - This allows us to fix some long-standing issues with `OneWayToSource` bindings - Expression nodes have been refactored - No longer split between `Avalonia.Base` and `Avalonia.Markup` - Categorize them according to whether they use reflection or not A few tests are failing around binding warnings: this is because the next step here is to fix binding warnings. * Make default binding Source = UnsetProperty. Null is a theoretically valid value for `Source`; setting it to null shouldn't mean "use the data context". * Move logging to BindingExpression. As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not. Fixes #5762 Fixes #9422 * Add compatibility hack for older compiled bindings. Previously, `CompiledBindingPathBuilder` didn't have a `TemplatedParent` method and instead the XAML compiler rewrite templated parent bindings to be a `$self.TemplateParent` property binding. resulting in extraneous logs. Add a constructor with an `apiVersion` to `CompiledBindingPathBuilder` which will be used by newer versions of the XAML compiler, and if a usage is detected using an `apiVersion` of 0, then upgrade `$self.TemplatedParent` to use a `TemplatedParentPathElement`. * Log errors from property accessors. * Don't log errors for named control bindings... ...on elements which aren't yet rooted. * Log errors for failed conversions. * Use consistent wording for binding warnings. "Could not convert" instead of "Cannot convert". * Log warnings for converter exceptions. * Don't convert new TargetTypeConverters each time. * Added failing test for implicit conversion. * Support cast operators in compiled bindings. A bit of a hack as we'd ideally not be using reflection when using compiled bindings. * This shouldn't be a public API. Should only be used for tests. * Make enum/int conversion work. * Check for SetValue equality after conversion. And also use "identity equals" where value types and strings use `object.Equals` and reference types use `object.ReferenceEquals`. * Added ConverterCulture back to bindings. * Fix merge error. Removed deleted files from csproj that were re-added due to indentation changes. * Use BindingExpression directly in ValueStoe. * Introduce BindingExpressionBase. And `UntypedBindingExpressionBase`. * Make TemplateBinding a BindingExpression. * Make DynamicResource use a BindingExpression. * WIP: Start exposing a BindingExpression API. * Finish exposing a BindingExpression API. * Fix OneTimeBinding. * Remove unneeded classes/methods. * Don't call obsolete API. * Make BindingExpressionBase the public API. This matches WPF's API. * Added BindingExpressionBase.UpdateTarget. * Initial implementation of UpdateSourceTrigger. * Don't use weak references for values. If they're boxed values, they can get collected. * No need for virtual/generic methods here now. * Reintroduce support for binding anchors. Turns out these were needed by animations, just our animation system has no unit tests so I missed that fact earlier. Add a basic animation unit test that fails without anchor support, and add binding anchors back in. Currently a private API as I suspect this feature shouldn't be needed outside the framework. * Include new property in clone. And add real-life example of `UpdateSourceTrigger=LostFocus` to BindingDemo. * Fix merge error. * Updated BindingExpression tests. - Make them run for both compiled and reflection bindings (found a bunch of tests that fail with compiled bindings) - Make them not depend on converting the `BindingExpression` to an observable and instead test the end result of the binding on an `AvaloniaObject` * Fix compiled binding indexer tests. * Use data validation plugins in PropertyAccessorNode. Added a warning suppression for now: we may need a separate `DataValidators` list for AOT-friendly plugins. * Don't separate plugins by reflection. `DataAnnotationsValidationPlugin` is public and so it can't be moved. No point in moving the others if this one will be in the wrong place. * Remove unneeded methods. * Make reflection binding tests use a string. Convert the `System.Linq.Expression` to a string and then use this, as reflection bindings will always be instanced with a string path. * Added TODO12 plan for IBinding2. * Use more specific exception. * Fix nits from code review. * Make expression nodes sealed where possible. * Unsubscribe on Stop, don't re-subscribe. D'oh. * Tweak ExpressionNode lists. Saves a few K in benchmarks and it's a cleaner API. * Add a pooled option in BindingExpressionGrammar. Micro-optimization. * Avoid allocations when enumerating binding plugins. * Add IBinding2 support to observable bind overloads. In the case of `TemplateBinding`, the `IObservable<object?>` bind overload is selected by C#. Add an explicit check for an `IBinding2` here to use the more performant code-path. * Remove disposed binding from ImmediateBindingFrame. * Added TemplateBinding benchmarks. * Remove duplicate items. Seems to have been caused by a merge error. * Fix exception when closing color picker. And add tests. * Don't skip converter when binding to self. * Don't pass UnsetValue to converters. This follows WPF behavior. * Log element name if present. More useful than just logging the control hash code. * Respect binding priority. * Throw on mismatched binding priorities. We don't want to respect the binding priority in this case as it breaks `TemplateBindings` when the default `LocalValue` priority is passed. Instead make sure that the priority parameter matches that of the expression. This reverts commit a72765d. * Convert to target type in TemplateBinding. * Short-circuit target type conversion for same types.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
After enabling binding error logging in my app I've noticed that there are literally thousands of errors reported every time I do something.
Many are reported when binding is initialized but before
DataContextis set. This causes "null target" notifications to be raised and logged.Examples from ControlCatalog:
To Reproduce
ExpressionNode.TargetNullNotificationExpected behavior
I think logging errors before
DataContextis set only causes confusion and degrades performance. One might think that binding has an actual problem but said binding will function correctly as soon asDataContextis set.Since general UI creation is like
DataContextwe can't expect
DataContextto be set while initializing objects.Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: