Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error logged to output window when binding to Run.Text #9422

Closed
tristanlabelle opened this issue Nov 11, 2022 · 4 comments · Fixed by #13970
Closed

Error logged to output window when binding to Run.Text #9422

tristanlabelle opened this issue Nov 11, 2022 · 4 comments · Fixed by #13970
Assignees
Labels
Milestone

Comments

@tristanlabelle
Copy link
Contributor

Describe the bug
When binding to the Run.Text property, an error is logged to the output window, even though the binding works properly.

To Reproduce
Steps to reproduce the behavior:

Add this xaml to an Avalonia project, like MobileSandbox:

<TextBlock>
  <Run Text="{Binding MyText}"/>
</TextBlock>

Create the corresponding MyText property on the ViewModel.

Run the program and see output window:

[Binding]Error in binding to 'Avalonia.Controls.Documents.Run'.'Text': 'Null value in expression '{empty}' at ''.'(Run #4861097)

The binding eventually re-executes and works, but this behavior does not happen when binding <TextBlock Text="{Binding MyText}"/> directly.

Expected behavior
There should not be an error produced in the output window.

Desktop:

  • OS: Windows 11
  • Version 0.11.0-preview4
@Gillibald Gillibald self-assigned this Nov 11, 2022
@Gillibald Gillibald added this to the 11.0 milestone Nov 21, 2022
@maxkatz6 maxkatz6 modified the milestones: 11.0, 11.x Jul 5, 2023
@RobertBeekman
Copy link

RobertBeekman commented Aug 17, 2023

I spent quite some time debugging laggy layout passes because of this.

Because the logging takes place during layout and takes relatively long, I'm seeing noticeable UI lag during animations. Unfortunately this makes Run unusable in complex views if you need smooth animations.

Looking forward to a fix! :)

@grokys
Copy link
Member

grokys commented Sep 11, 2023

I'm working on a binding refactor which should give the binding system enough information to know when and when not to log errors. In the meantime, if this is causing problems you can turn off logging in the AppBuilder

grokys added a commit that referenced this issue Sep 21, 2023
As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not.

Fixes #5762
Fixes #9422
grokys added a commit that referenced this issue Sep 21, 2023
As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not.

Fixes #5762
Fixes #9422
grokys added a commit that referenced this issue Sep 22, 2023
As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not.

Fixes #5762
Fixes #9422
grokys added a commit that referenced this issue Sep 22, 2023
As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not.

Fixes #5762
Fixes #9422
grokys added a commit that referenced this issue Sep 22, 2023
As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not.

Fixes #5762
Fixes #9422
grokys added a commit that referenced this issue Oct 16, 2023
As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not.

Fixes #5762
Fixes #9422
grokys added a commit that referenced this issue Oct 18, 2023
As `BindingExpression` now has enough information to decide when it's appropriate to log an error/warning or not.

Fixes #5762
Fixes #9422
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.
@ashelleyPurdue
Copy link

ashelleyPurdue commented Jul 6, 2024

I still have this exact same problem in version 11.0.10. Are you sure the refactor fixed it?

@timunie
Copy link
Contributor

timunie commented Jul 6, 2024

Need to test 11.1 rc2 to judge that, not 11.0.10 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants