-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
View's DataContext is getting set to the parent's view DataContext at initialization, triggering the error "Unable to cast object of type" #17649
Comments
Please extract a minimum sample and file it here. We cannot debug into complete Apps for free. Thx for your understanding. |
@timunie wdym for free? 💀 I've literally provided steps to reproduce. Oh well. |
This actually works properly if you don't set the data context on the <ItemsControl.ItemTemplate>
<DataTemplate>
<Border Margin="0,5" BoxShadow="0 5 5 0 #181818">
<v:ChildView />
</Border>
</DataTemplate>
</ItemsControl.ItemTemplate> |
Reading through large descriptions and screenshots puts an increased burden on maintainers leading to less work being done on Avalonia and more work being done on communicating+reproducing. When required, those scenarios can require paid support. That said, the minimal repro provided was good. There's no need to pass-down
Personally, I only use case 1. I very rarely assign Not sure what the underlying reason why |
This seems to be a duplicate #17643 . At the moment {Binding} don't work correctly. I'll leave this one open and close the other due to better title 🙂 |
same |
Is this a regression (11.0.10 -> 11.2.2) that is planned to be fixed? |
Planned but no due date, since there is a really easy way around it |
Describe the bug
I've updated my project from Avalonia 11.0.9 to 11.2.2 and my visual tree got broken.
When i got to check out what's actually happening, in the logs the following line appeared:
And many-many more of similar messages in nested controls.
Resulting in the actual controls' properties not being binded to anything.
'Strange' -- i thought, because in AXAML i am explicitly stating that i want the 'HomeView' to have bind it's
DataContext
to the propertyMainWindowViewModel.HomeViewModel
MainView.axaml
I've looked up other issues (#17592)
And thought that similarly, it may have been my own mistake, but no. In the
HomeView.axaml
there isn't a single trace referencingMainWindowViewModel
HomeView.axaml
And the actual property also has the appropriate type:
So i went do debug, subscribed to event
DataContextChanged
in the HomeView.axaml.cs class like so:in the debugger i found that the HomeView's
DataConext
is actually being set to theMainWindowViewModel
what? how? why?, -- i went and check the stack trace, to find out where that has happened.
I found that it's happening in the setter of
MainWindow.DataConext
in theOnFrameworkInitializationComplete
method inApp.cs
classI've additionally made a sanity check that
MainWindow
is not, in fact, aHomeView
After that, the
DataContext
is being set properly. But all of the errors are already happened.And so, as the result, the
DataContext
of the controls is being set properly at the end of the day, but the bindings on the controls properties are broken, and are not resolved automatically onDataContext
changeHomeView's
DataContext
is set properlyCustom control's
DataContext
is set properlyThe data is present
But the
Text
property onTextBlock
inside a custom control is UnsetTo Reproduce
OnFrameworkInitializationCompleted
inApp.cs
Expected behavior
The children controls
DataContext
not being set to the parentDataContext
, but immediately to the appropriate property, if it is present.--or--
The binding being restored when the
DataContext
changes to the object with appropriate type.Avalonia version
11.2.2
OS
Windows, Android
Additional context
SatteliteSummary.axaml
The text was updated successfully, but these errors were encountered: